Esporre il middleware legacy SAP in modo sicuro con PaaS di Azure
L'abilitazione di sistemi interni e partner esterni per interagire con i back-end SAP è un requisito comune. Gli scenari SAP esistenti spesso si basano sul middleware SAP Process Orchestration (PO) o sull'integrazione dei processi (PI) legacy per le esigenze di integrazione e trasformazione. Per semplicità, questo articolo usa il termine SAP Process Orchestration per fare riferimento a entrambe le offerte.
Questo articolo descrive le opzioni di configurazione in Azure, con particolare attenzione alle implementazioni con connessione Internet.
Nota
SAP menziona SAP Integration Suite, in particolare SAP Cloud Integration, in esecuzione su Business Technology Platform (BTP) come successore per SAP PO e PI. Sia la piattaforma BTP che i servizi sono disponibili in Azure. Per altre informazioni, vedere SAP Discovery Center. Per altre informazioni sulla sequenza temporale del supporto della manutenzione per i componenti legacy, vedere la nota sap OSS 1648480.
Panoramica
Le implementazioni esistenti basate sul middleware SAP si sono spesso affidate alla tecnologia di distribuzione proprietaria di SAP denominata SAP Web Dispatcher. Questa tecnologia opera al livello 7 del modello OSI. Funge da proxy inverso e risolve le esigenze di bilanciamento del carico per carichi di lavoro di applicazioni SAP downstream, ad esempio SAP Enterprise Resource Planning (ERP), SAP Gateway o SAP Process Orchestration.
Gli approcci di invio includono proxy inversi tradizionali come Apache, le opzioni PaaS (Platform as a Service) come Azure Load Balancer e sap Web Dispatcher. I concetti generali descritti in questo articolo si applicano alle opzioni indicate. Per indicazioni sull'uso di servizi di bilanciamento del carico non SAP, vedere il wiki di SAP.
Nota
Tutte le configurazioni descritte in questo articolo presuppongono una topologia di rete hub-spoke, in cui i servizi condivisi vengono distribuiti nell'hub. In base alla criticità di SAP, potrebbe essere necessario un isolamento ancora maggiore. Per altre informazioni, vedere la guida alla progettazione SAP per le reti perimetrali.
Servizi primari di Azure
app Azure lication Gateway gestisce il routing HTTP privato e basato su Internet pubblico e interno, insieme al tunneling crittografato tra sottoscrizioni di Azure. Gli esempi includono la sicurezza e la scalabilità automatica.
app Azure lication Gateway è incentrato sull'esposizione di applicazioni Web, quindi offre un web application firewall (WAF). I carichi di lavoro in altre reti virtuali che comunicheranno con SAP tramite app Azure lication Gateway possono essere connessi tramite collegamenti privati, anche tra tenant.
Firewall di Azure gestisce il routing privato pubblico basato su Internet e interno per i tipi di traffico sui livelli da 4 a 7 del modello OSI. Offre filtri e intelligence per le minacce che vengono inseriti direttamente da Microsoft Security.
Azure Gestione API gestisce il routing privato pubblico basato su Internet e interno specificamente per le API. Offre la limitazione delle richieste, la quota di utilizzo e i limiti, funzionalità di governance come criteri e chiavi API per suddividere i servizi per ogni client.
Azure Gateway VPN e Azure ExpressRoute fungono da punti di ingresso alle reti locali. Sono abbreviati nei diagrammi come VPN e XR.
Considerazioni sull'installazione
Le esigenze dell'architettura di integrazione variano a seconda dell'interfaccia usata da un'organizzazione. Le tecnologie proprietarie SAP, ad esempio il framework IDoc (Intermediate Document), l'interfaccia BAPI (Business Application Programming Interface), le chiamate di funzioni remote transazionali (tRFCs) o le RFC semplici richiedono un ambiente di runtime specifico. Operano sui livelli da 4 a 7 del modello OSI, a differenza delle API moderne che in genere si basano sulla comunicazione basata su HTP (livello 7 del modello OSI). Per questo motivo, le interfacce non possono essere trattate allo stesso modo.
Questo articolo è incentrato sulle API moderne e su HTTP, inclusi scenari di integrazione come l'applicabilità 2 (AS2). Ftp (File Transfer Protocol) funge da esempio per gestire le esigenze di integrazione non HTTP. Per altre informazioni sulle soluzioni di bilanciamento del carico Microsoft, vedere Opzioni di bilanciamento del carico.
Nota
SAP pubblica connettori dedicati per le interfacce proprietarie. Vedere la documentazione di SAP per Java e .NET, ad esempio. Sono supportati anche dai gateway Microsoft. Tenere presente che IDocs può anche essere pubblicato tramite HTTP.
I problemi di sicurezza richiedono l'uso dei firewall per protocolli di livello inferiore e WAF per gestire il traffico basato su HTTP con Transport Layer Security (TLS). Per essere efficaci, le sessioni TLS devono essere terminate a livello di WAF. Per supportare approcci senza attendibilità, è consigliabile crittografare nuovamente in seguito per fornire la crittografia end-to-encryption.
I protocolli di integrazione, ad esempio AS2, possono generare avvisi usando regole WAF standard. È consigliabile usare la cartella di lavoro di valutazione di WAF gateway applicazione per identificare e comprendere meglio il motivo per cui viene attivata la regola, in modo da poter correggere in modo efficace e sicuro. Open Web Application Security Project (OWASP) fornisce le regole standard. Per una sessione video dettagliata su questo argomento con particolare attenzione all'esposizione di SAP Fiori, vedere il webcast SAP in Azure.
È possibile migliorare ulteriormente la sicurezza usando mutual TLS (mTLS), detto anche autenticazione reciproca. A differenza di TLS normale, verifica l'identità client.
Nota
I pool di macchine virtuali richiedono un servizio di bilanciamento del carico. Per una migliore leggibilità, i diagrammi di questo articolo non mostrano un servizio di bilanciamento del carico.
Nota
Se non sono necessarie funzionalità di bilanciamento specifiche di SAP fornite da SAP Web Dispatcher, è possibile sostituirle con Azure Load Balancer. Questa sostituzione offre il vantaggio di un'offerta PaaS gestita anziché di una configurazione IaaS (Infrastructure as a Service).
Scenario: connettività HTTP in ingresso incentrata
SAP Web Dispatcher non offre un WAF. Per questo motivo, è consigliabile app Azure lication Gateway per una configurazione più sicura. Sap Web Dispatcher e Process Orchestration rimangono responsabili per proteggere il back-end SAP dall'overload delle richieste con linee guida per il ridimensionamento e limiti di richieste simultanee. Nessuna funzionalità di limitazione è disponibile nei carichi di lavoro SAP.
È possibile evitare l'accesso involontario tramite elenchi di controllo di accesso in SAP Web Dispatcher.
Uno degli scenari per la comunicazione di orchestrazione dei processi SAP è il flusso in ingresso. Il traffico potrebbe provenire da app locali, esterne o utenti o da un sistema interno. L'esempio seguente è incentrato su HTTPS.
Scenario: connettività HTTP/FTP in uscita evidenziata
Per la direzione di comunicazione inversa, SAP Process Orchestration può usare il routing di rete virtuale per raggiungere carichi di lavoro locali o destinazioni basate su Internet tramite l'interruzione Internet. app Azure lication Gateway funge da proxy inverso in tali scenari. Per le comunicazioni non HTTP, è consigliabile aggiungere Firewall di Azure. Per altre informazioni, vedere Scenario: Basato su file e Confronto dei componenti del gateway più avanti in questo articolo.
Lo scenario in uscita seguente illustra due metodi possibili. Uno usa HTTPS tramite app Azure lication Gateway che chiama un servizio Web (ad esempio, scheda SOAP). L'altro usa FTP su SSH (SFTP) tramite Firewall di Azure il trasferimento di file al server SFTP di un partner aziendale.
Scenario: Gestione API incentrato
Rispetto agli scenari per la connettività in ingresso e in uscita, l'introduzione di Azure Gestione API in modalità interna (solo IP privato e integrazione di rete virtuale) aggiunge funzionalità predefinite come:
- Limitazione.
- Governance api.
- Opzioni di sicurezza aggiuntive, ad esempio i flussi di autenticazione moderni.
- Integrazione di Microsoft Entra ID .
- L'opportunità di aggiungere API SAP a una soluzione API centrale in tutta l'azienda.
Quando non è necessario un WAF, è possibile distribuire Azure Gestione API in modalità esterna usando un indirizzo IP pubblico. Questa distribuzione semplifica la configurazione mantenendo al tempo stesso le funzionalità di limitazione e governance delle API. La protezione di base viene implementata per tutte le offerte PaaS di Azure.
Scenario: Copertura globale
app Azure lication Gateway è un servizio associato a un'area. Rispetto agli scenari precedenti, Frontdoor di Azure garantisce il routing globale tra aree, incluso un web application firewall. Per informazioni dettagliate sulle differenze, vedere questo confronto.
Il diagramma seguente condensa SAP Web Dispatcher, SAP Process Orchestration e back-end in un'unica immagine per migliorare la leggibilità.
Scenario: basato su file
I protocolli non HTTP come FTP non possono essere risolti con Azure Gestione API, gateway applicazione o Frontdoor di Azure, come illustrato negli scenari precedenti. Al contrario, l'istanza di Firewall di Azure gestita o l'appliance virtuale di rete equivalente assume il ruolo di protezione delle richieste in ingresso.
I file devono essere archiviati prima che SAP possa elaborarli. È consigliabile usare SFTP. Archiviazione BLOB di Azure supporta SFTP in modo nativo.
Le opzioni SFTP alternative sono disponibili in Azure Marketplace, se necessario.
Il diagramma seguente illustra una variante di questo scenario con destinazioni di integrazione esternamente e locali. Diversi tipi di FTP sicuro illustrano il percorso di comunicazione.
Per informazioni dettagliate sulle condivisioni file NFS (Network File System) come alternativa all'archiviazione BLOB, vedere Condivisioni file NFS in File di Azure.
Scenario: SAP RISE specifico
Le distribuzioni SAP RISE sono tecnicamente identiche agli scenari descritti in precedenza, con l'eccezione che SAP gestisce il carico di lavoro SAP di destinazione. I concetti descritti possono essere applicati qui.
I diagrammi seguenti illustrano due configurazioni come esempi. Per altre informazioni, vedere la guida di riferimento a SAP RISE.
Importante
Contattare SAP per assicurarsi che le porte di comunicazione per lo scenario siano consentite e aperte nei gruppi di sicurezza di rete.
HTTP in ingresso
Nella prima configurazione, il cliente gestisce il livello di integrazione, inclusa l'orchestrazione del processo SAP e il percorso in ingresso completo. Solo la destinazione SAP finale viene eseguita nella sottoscrizione RISE. La comunicazione con il carico di lavoro ospitato da RISE viene configurata tramite il peering di rete virtuale, in genere tramite l'hub. Una potenziale integrazione potrebbe essere IDocs inviata al servizio /sap/bc/idoc_xml Web SAP ERP da un'entità esterna.
Questo secondo esempio mostra un'installazione in cui SAP RISE esegue l'intera catena di integrazione, ad eccezione del livello Gestione API.
File in uscita
In questo scenario, l'istanza di Orchestrazione di processi gestiti da SAP scrive i file nella condivisione file gestita dal cliente in Azure o in un carico di lavoro in locale. Il cliente gestisce l'interruzione.
Confronto tra le configurazioni del gateway
Nota
Le metriche relative alle prestazioni e ai costi presuppongono livelli di livello di produzione. Per altre informazioni, vedere Calcolatore prezzi di Azure. Vedere anche gli articoli seguenti: prestazioni Firewall di Azure, supporto per traffico elevato gateway applicazione e Capacità di un'istanza di Azure Gestione API.
A seconda dei protocolli di integrazione in uso, potrebbero essere necessari più componenti. Per altre informazioni sui vantaggi delle varie combinazioni di concatenamento app Azure gateway con Firewall di Azure, vedere Firewall di Azure e gateway applicazione per le reti virtuali.
Regola di integrazione generale
Per determinare quali scenari di integrazione descritti in questo articolo meglio soddisfano i requisiti, valutarli caso per caso. Valutare la possibilità di abilitare le funzionalità seguenti:
Limitazione delle richieste tramite Gestione API
Limiti delle richieste simultanee per SAP Web Dispatcher
Disponibilità elevata e ripristino di emergenza per carichi di lavoro di integrazione SAP basati su macchine virtuali
Meccanismi di autenticazione moderni come OAuth2, se applicabile
Un archivio chiavi gestito come Azure Key Vault per tutte le credenziali, i certificati e le chiavi coinvolti
Alternative all'orchestrazione dei processi SAP con Azure Integration Services
Con il portfolio di Azure Integration Services, è possibile gestire in modo nativo gli scenari di integrazione coperti da SAP Process Orchestration. Per informazioni dettagliate su come progettare modelli SAP IFlow tramite mezzi nativi del cloud, vedere questa serie di blog. La guida al connettore contiene altri dettagli su AS2 ed EDIFACT.
Per altre informazioni, vedere i connettori App per la logica di Azure per le interfacce SAP desiderate.
Passaggi successivi
Proteggere le API con il gateway applicazione e Gestione API
Integrare Gestione API in una rete virtuale interna con gateway applicazione
Informazioni sul waf di gateway applicazione per SAP
Comprendere le implicazioni della combinazione di Firewall di Azure e gateway di app Azure lication