Exposer de manière sécurisée l’intergiciel hérité SAP avec Azure PaaS
Le fait de permettre aux systèmes internes et aux partenaires externes d’interagir avec les back-ends SAP est une exigence courante. Les paysages SAP existants s’appuient souvent sur le middleware (intergiciel) hérité SAP Process Orchestration (PO) ou Process Integration (PI) pour leurs besoins d’intégration et de transformation. Pour plus de simplicité, cet article utilise le terme d’orchestration de processus SAP pour faire référence aux deux offres.
Cet article décrit les options de configuration sur Azure, en mettant l’accent sur les implémentations accessibles sur Internet.
Notes
SAP mentionne SAP Integration Suite, en particulier SAP Cloud Integration, s’exécutant sur Business Technology Platform (BTP) comme successeur de SAP PO et PI. La plateforme BTP et les services sont disponibles sur Azure. Pour plus d’informations, consultez SAP Discovery Center. Pour plus d’informations sur la chronologie de prise en charge de la maintenance pour le composant hérité, consultez la note SAP OSS 1648480.
Vue d’ensemble
Les implémentations existantes basées sur l’intergiciel SAP ont souvent reposé sur la technologie de répartition propriétaire de SAP appelée SAP Web Dispatcher. Cette technologie fonctionne sur la couche 7 du modèle OSI. Elle agit comme un proxy inverse et répond aux besoins d’équilibrage de charge pour les charges de travail d’application SAP en aval telles que SAP Enterprise Resource Planning (ERP), SAP Gateway ou SAP Process Orchestration.
Les approches de répartition incluent les proxys inverses traditionnels, comme Apache, les options PaaS (platform as a service), comme Azure Load Balancer, et le répartiteur SAP Web Dispatcher strict. Les concepts généraux décrits dans cet article s’appliquent aux options mentionnées. Pour obtenir des conseils sur l’utilisation d’équilibreurs de charge non-SAP, consultez le wiki de SAP.
Notes
Toutes les configurations décrites dans cet article supposent une topologie hub-and-spoke, où les services partagés sont déployés dans le hub. En fonction de la criticité de SAP, vous pouvez avoir besoin d’encore plus d’isolation. Pour plus d’informations, consultez le guide de conception SAP pour les réseaux de périmètre.
Principaux services Azure
Azure Application Gateway gère le routage HTTP Internet public et privé interne ainsi que le tunneling chiffré entre les abonnements Azure. À titre d’exemples, citons la sécurité et la mise à l’échelle automatique.
Azure Application Gateway se concentrant sur l’exposition d’applications web, il offre un pare-feu d’applications web (WAF). Les charges de travail d’autres réseaux virtuels qui communiquent avec SAP via Azure Application Gateway peuvent être connectées via des liaisons privées, même entre locataires.
Pare-feu Azure gère le routage privé interne et Internet public pour les types de trafic sur les couches 4 à 7 du modèle OSI. Il fournit le filtrage et le renseignement sur les menaces directement depuis Microsoft Security.
Gestion des API Azure gère le routage privé interne et Internet public spécifiquement pour les API. Il offre la limitation des demandes, un quota d’utilisation et des limites, des fonctionnalités de gouvernance telles que les stratégies et les clés API pour ventiler les services par client.
La passerelle Azure VPN et Azure ExpressRoute servent de points d’entrée aux réseaux locaux. Ils apparaissent dans les diagrammes sous les formes abrégées VPN et XR.
Considérations relatives à la configuration
Les besoins de l’architecture d’intégration varient en fonction de l’interface qu’utilise une organisation. Les technologies propriétaires SAP telles que le framework IDoc (Intermediate Document), l’interface de programmation d’applications métiers (BAPI), les appels de fonction à distance transactionnels (tRFC) ou les RFC bruts nécessitent un environnement d’exécution spécifique. Ils fonctionnent sur les couches 4 à 7 du modèle OSI, contrairement aux API modernes qui reposent généralement sur la communication HTP (couche 7 du modèle OSI). De ce fait, les interfaces ne peuvent pas être traitées de la même façon.
Cet article se concentre sur les API modernes et HTTP, notamment les scénarios d’intégration comme AS2 (Applicability Statement 2). Le protocole FTP (File Transfer Protocol) sert d’exemple pour gérer les besoins d’intégration non-HTTP. Pour plus d’informations sur les solutions d’équilibrage de charge Microsoft, consultez Options d’équilibrage de charge.
Notes
SAP publie des connecteurs dédiés pour ses interfaces propriétaires. Consultez la documentation de SAP pour Java et .NET, par exemple. Ils sont également pris en charge par les passerelles Microsoft. N’oubliez pas que les IDocs peuvent également être publiés via HTTP.
Les problèmes de sécurité nécessitent l’utilisation de pare-feu pour les protocoles de niveau inférieur et de WAF pour traiter le trafic HTTP avec le protocole TLS. Pour être efficaces, les sessions TLS doivent être arrêtées au niveau du WAF. Pour prendre en charge les approches Confiance Zéro, nous vous recommandons de procéder postérieurement à un nouveau chiffrement pour fournir un chiffrement de bout en bout.
Les protocoles d’intégration tels qu’AS2 peuvent déclencher des alertes en utilisant des règles WAF standard. Nous vous recommandons d’utiliser le classeur de triage WAF Application Gateway pour identifier et mieux comprendre la raison pour laquelle la règle est déclenchée, afin de pouvoir procéder à une correction de manière efficace et sécurisée. OWASP (Open Web Application Security Project) fournit les règles standard. Pour une session vidéo détaillée sur ce sujet, qui met l’accent sur l’exposition SAP Fiori, consultez l’émission web SAP sur Azure.
Vous pouvez améliorer davantage la sécurité en utilisant le protocole TLS mutuel (mTLS), également appelé authentification mutuelle. Contrairement au protocole TLS normal, il vérifie l’identité du client.
Notes
Les pools de machines virtuelles nécessitent un équilibreur de charge. Pour une meilleure lisibilité, les diagrammes de cet article ne montrent pas d’équilibreur de charge.
Notes
Si vous n’avez pas besoin de fonctionnalités d’équilibrage spécifiques à SAP fournies par SAP Web Dispatcher, vous pouvez les remplacer par Azure Load Balancer. Ce remplacement offre l’avantage d’une offre PaaS managée au lieu d’une configuration IaaS (infrastructure as a service).
Scénario : Connectivité HTTP entrante
SAP Web Dispatcher n’offre pas de WAF. De ce fait, nous recommandons Azure Application Gateway pour une configuration plus sécurisée. SAP Web Dispatcher et Process Orchestration restent chargés d’aider à protéger le back-end SAP contre la surcharge des requêtes en suivant des conseils de dimensionnement et des limites de requête simultanées. Aucune fonctionnalité de limitation n’est disponible dans les charges de travail SAP.
Vous pouvez éviter l’accès involontaire via des listes de contrôle d’accès sur SAP Web Dispatcher.
L’un des scénarios de communication de SAP Process Orchestration est un flux entrant. Le trafic peut provenir d’applications ou d’utilisateurs externes locaux ou d’un système interne. L’exemple suivant se concentre sur HTTPS.
Scénario : Connectivité HTTP/FTP sortante
Pour le sens de communication inverse, SAP Process Orchestration peut utiliser le routage de réseau virtuel pour atteindre des charges de travail locales ou des cibles basées sur Internet via le breakout Internet. Azure Application Gateway agit comme un proxy inverse dans de tels scénarios. Pour la communication non-HTTP, envisagez d’ajouter Pare-feu Azure. Pour plus d’informations, consultez Scénario : Basé sur des fichiers et Comparaison des composants de passerelle plus loin dans cet article.
Le scénario de flux sortant suivant montre deux méthodes possibles. L’une utilise HTTPS par le biais d’Azure Application Gateway pour l’appel d’un service web (par exemple l’adaptateur SOAP). L’autre utilise FTP sur SSH (SFTP) par le biais de Pare-feu Azure pour le transfert de fichiers vers le serveur SFTP d’un partenaire commercial.
Scénario 2 : Gestion des API
Par rapport aux scénarios de connectivité entrante et sortante, l’introduction de Gestion des API Azure en mode interne (intégration d’adresses IP privées uniquement et de réseau virtuel) ajoute des fonctionnalités intégrées telles que :
- Limitation.
- Gouvernance des API.
- Options de sécurité supplémentaires telles que les flux d’authentification modernes.
- Intégration Microsoft Entra ID.
- La possibilité d’ajouter des API SAP à une solution d’API centralisée au sein de l’entreprise.
Quand vous n’avez pas besoin d’un WAF, vous pouvez déployer Gestion des API Azure en mode externe en utilisant une adresse IP publique. Ce déploiement simplifie la configuration tout en conservant les fonctionnalités de limitation et de gouvernance des API. La protection de base est implémentée pour toutes les offres PaaS Azure.
Scénario : Portée globale
Azure Application Gateway est un service lié aux régions. Par rapport aux scénarios précédents, Azure Front Door garantit un routage global inter-régions, y compris un pare-feu d’applications web. Pour plus d’informations sur les différences, consultez cette comparaison.
Le diagramme suivant condense SAP Web Dispatcher, SAP Process Orchestration et le back-end en une image unique pour une meilleure lisibilité.
Scénario : Basé sur des fichiers
Les protocoles non-HTTP tels que FTP ne peuvent pas être traités avec Gestion des API Azure, Application Gateway ou Azure Front Door, comme illustré dans les scénarios précédents. Au lieu de cela, l’instance de Pare-feu Azure managée ou l’appliance virtuelle réseau équivalente assure le rôle de sécurisation des demandes entrantes.
Les fichiers doivent être stockés avant que SAP puisse les traiter. Nous vous recommandons d’utiliser SFTP. Stockage Blob Azure prend en charge SFTP en mode natif.
D’autres options SFTP sont disponibles dans la Place de marché Azure, si nécessaire.
Le diagramme suivant montre une variante de ce scénario avec des cibles d’intégration en externe et localement. Différents types de FTP sécurisé illustrent le chemin de communication.
Pour plus d’insights sur les partages de fichiers NFS (Network File System) comme alternative au Stockage Blob, consultez Partages de fichiers NFS dans Azure Files.
Scénario : Spécifique à SAP RISE
Les déploiements SAP RISE sont techniquement identiques aux scénarios décrits précédemment, à la différence que SAP gère directement la charge de travail SAP cible. Les concepts décrits peuvent être appliqués ici.
Les diagrammes suivants montrent deux exemples de configuration. Pour plus d’informations, consultez notre guide de référence sur SAP RISE.
Important
Contactez SAP pour vous assurer que les ports de communication de votre scénario sont autorisés et ouverts dans les NSG.
Connectivité HTTP entrante
Dans la première configuration, le client régit la couche d’intégration, incluant SAP Process Orchestration et le chemin entrant complet. Seule la cible SAP finale s’exécute sur l’abonnement RISE. La communication vers la charge de travail hébergée RISE est configurée par le biais de l’appairage de réseaux virtuels, généralement sur le hub. Une intégration pourrait être la publication d’IDocs sur le service web SAP ERP /sap/bc/idoc_xml par une partie externe.
Ce deuxième exemple montre une configuration où SAP RISE exécute l’ensemble de la chaîne d’intégration, à l’exception de la couche Gestion des API.
Connectivité HTTP sortante
Dans ce scénario, l’instance Process Orchestration managée par SAP écrit des fichiers dans le partage de fichiers géré par le client sur Azure ou dans une charge de travail locale. Le client gère le breakout.
Comparaison des configurations de passerelle
Notes
Les métriques de performances et de coût supposent des niveaux de qualité production. Pour plus d’informations, consultez la calculatrice de prix Azure. Consultez également les articles suivants : Performances du Pare-feu Azure, Prendre en charge le trafic élevé avec Application Gateway et Capacité d’une instance du service Gestion des API Azure.
Selon les protocoles d’intégration que vous utilisez, vous aurez peut-être besoin de plusieurs composants. Pour plus d’informations sur les avantages des différentes combinaisons de chaînage d’Azure Application Gateway avec Pare-feu Azure, consultez Pare-feu Azure et Application Gateway pour les réseaux virtuels.
Règle de base de l’intégration
Pour déterminer les scénarios d’intégration décrits dans cet article qui répondent le mieux à vos besoins, évaluez-les au cas par cas. Envisagez d’activer les fonctionnalités suivantes :
Limitation des demandes en utilisant Gestion des API
Limites des demandes simultanées sur SAP Web Dispatcher
TLS mutuel pour vérifier le client et le récepteur
Pare-feu Azure pour les intégrations non-HTTP
Haute disponibilité et reprise d’activité pour des charges de travail d’intégration SAP basées sur des machines virtuelles
Mécanismes d’authentification modernes comme OAuth2, le cas échéant
Un magasin de clés managé comme Azure Key Vault pour la totalité des informations d’identification, certificats et clés impliqués
Alternatives à SAP Process Orchestration avec les services d’intégration Azure
Avec le portefeuille Azure Integration Services, vous pouvez résoudre en mode natif les scénarios d’intégration couverts par SAP Process Orchestration. Pour plus d’insights sur la conception de modèles IFlow SAP avec des moyens natifs Cloud, consultez cette série de blog. Le guide des connecteurs contient des détails supplémentaires sur AS2 et EDIFACT.
Pour plus d’informations, consultez Connecteurs Azure Logic Apps pour vos interfaces SAP souhaitées.
Étapes suivantes
Protéger les API avec Application Gateway et Gestion des API
Intégrer le service Gestion des API dans un réseau virtuel interne avec Application Gateway
Comprendre le WAF Application Gateway pour SAP
Comprendre les implications de la combinaison de Pare-feu Azure et d’Azure Application Gateway