Modifier

Partager via

Connexions Internet entrantes et sortantes pour SAP sur Azure

Machines virtuelles Azure
Réseau virtuel Azure
Azure Application Gateway
Azure Load Balancer

Cet article décrit les pratiques éprouvées permettant d’améliorer la sécurité des connexions Internet entrantes et sortantes pour votre infrastructure SAP sur Azure.

Architecture

Diagramme montrant une solution de communication avec Internet pour SAP sur Azure.

Téléchargez un fichier Visio des architectures de cet article.

Cette solution illustre un environnement de production commun. Vous pouvez réduire la taille et l’étendue de la configuration pour répondre à vos besoins. Cette réduction peut s’appliquer au paysage SAP : moins de machines virtuelles, pas de haute disponibilité, ni de répartiteurs web SAP incorporés au lieu de machines virtuelles distinctes. Il peut également s’appliquer aux alternatives à la conception du réseau, comme décrit plus loin dans cet article.

Les exigences des clients, pilotées par les stratégies métier, nécessitent des adaptations à l’architecture, en particulier à la conception du réseau. Dans la mesure du possible, nous avons inclus des alternatives. De nombreuses solutions sont viables. Choisissez une approche adaptée à votre entreprise. Elle doit vous aider à sécuriser vos ressources Azure tout en offrant une solution performante.

La récupération d’urgence n’est pas couverte dans cette architecture. Pour la conception réseau, les mêmes principes et conception valides pour les régions de production primaire s’appliquent. Dans votre conception réseau, selon les applications protégées par la récupération d’urgence, envisagez d’activer la récupération d’urgence dans une autre région Azure. Pour plus d’informations, consultez l’article Vue d’ensemble de la récupération d’urgence et conseils sur l’infrastructure pour la charge de travail SAP

Workflow

  • Le réseau local se connecte à un hub central via Azure ExpressRoute. Le réseau virtuel hub contient un sous-réseau de passerelle, un sous-réseau Pare-feu Azure, un sous-réseau de services partagés et un sous-réseau Azure Application Gateway.
  • Le hub se connecte à un abonnement de production SAP via le peering de réseaux virtuels. Cet abonnement contient deux réseaux virtuels spoke :
    • Le réseau virtuel de périmètre SAP contient un sous-réseau d’application de périmètre.
    • Le réseau virtuel de production SAP contient un sous-réseau d’application et un sous-réseau de base de données.
  • L’abonnement hub et l’abonnement de production SAP se connectent à Internet via des adresses IP publiques.

Composants

Abonnements. Cette architecture implémente l’approche zone d’atterrissage Azure. Un abonnement Azure est utilisé pour chaque charge de travail. Un ou plusieurs abonnements sont utilisés pour les services informatiques centraux qui contiennent le hub réseau et les services partagés tels que les pare-feu ou Active Directory et DNS. Un autre abonnement est utilisé pour la charge de travail de production SAP. Utilisez le guide de décision dans le Cloud Adoption Framework pour Azure afin de déterminer la meilleure stratégie d’abonnement pour votre scénario.

Réseaux virtuels. Réseau virtuel Azure connecte les ressources Azure entre elles, avec une sécurité renforcée. Dans cette architecture, le réseau virtuel se connecte à un environnement local via une passerelle ExpressRoute ou de réseau privé virtuel (VPN) déployée dans le hub d’une topologie hub-and-spoke. Le paysage de production SAP utilise ses propres réseaux virtuels spoke. Deux réseaux virtuels spoke distincts effectuent différentes tâches et les sous-réseaux assurent la séparation du réseau.

La séparation en sous-réseaux par charge de travail facilite l’utilisation des groupes de sécurité réseau (NSG) afin de définir des règles de sécurité pour les machines virtuelles d’application ou les services Azure qui sont déployés.

Passerelle redondante interzone. Une passerelle connecte différents réseaux et étend votre réseau local sur le réseau virtuel Azure. Nous vous recommandons d’utiliser ExpressRoute pour créer des connexions privées qui n’utilisent pas l’Internet public. Vous pouvez aussi utiliser une connexion de site à site. Utilisez des passerelles Azure ExpressRoute ou VPN redondantes interzone pour vous protéger contre les défaillances de zone. Consultez l’article relatif aux passerelles de réseau virtuel redondantes interzones pour connaître les différences entre un déploiement zonal et un déploiement redondant interzone. Pour un déploiement de zone des passerelles, vous devez utiliser des adresses IP de référence SKU Standard.

NSG. Pour restreindre le trafic réseau vers et à partir du réseau virtuel, créez des groupes de sécurité réseau et affectez-les à des sous-réseaux spécifiques. Fournissez la sécurité pour les sous-réseaux individuels à l’aide de groupes de sécurité réseau spécifiques à la charge de travail.

Groupes de sécurité d’application. Pour définir des stratégies de sécurité réseau affinées dans vos groupes de sécurité réseau selon les charges de travail et centrées sur les applications, utilisez des groupes de sécurité d’application plutôt que des adresses IP explicites. À l’aide de groupes de sécurité d’application, vous pouvez regrouper les machines virtuelles selon l’objet de leur utilisation (par SID SAP, par exemple). Les groupes de sécurité d’applications aident à sécuriser les applications en filtrant le trafic à partir de segments approuvés de votre réseau.

Point de terminaison privé. De nombreux services Azure fonctionnent en tant que services publics, par conception accessible via Internet. Pour autoriser l’accès privé via votre plage de réseaux privés, vous pouvez utiliser des points de terminaison privés pour certains services. Les points de terminaison privés sont des interfaces réseau dans votre réseau virtuel. Ils apportent efficacement le service dans votre espace réseau privé.

Azure Application Gateway. Application Gateway est un équilibreur de charge du trafic web. Avec sa fonctionnalité Web Application Firewall, il s’agit du service idéal pour exposer des applications web à Internet avec une sécurité améliorée. Application Gateway peut servir des clients publics (Internet) ou privés, ou les deux, en fonction de la configuration.

Dans l’architecture, Application Gateway, à l’aide d’une adresse IP publique, autorise les connexions entrantes au paysage SAP via HTTPS. Son pool principal est constitué de deux machines virtuelles SAP Web Dispatcher ou plus, accessibles en tourniquet et assurant la haute disponibilité des services. La passerelle d’application est un proxy inverse et un équilibreur de charge du trafic web, mais il ne remplace pas SAP Web Dispatcher. SAP Web Dispatcher fournit une intégration d’application à vos systèmes SAP et inclut des fonctionnalités qui Application Gateway par elle-même ne fournissent pas. L’authentification cliente, lorsqu’elle atteint les systèmes SAP, est effectuée par la couche d’application SAP en mode natif ou via l’authentification unique. Lorsque vous activez la protection Azure DDoS, envisagez d’utiliser la référence SKU de protection réseau DDoS, car vous verrez des remises pour le pare-feu d’applications web Application Gateway.

Pour des performances optimales, activez la Prise en charge de HTTP/2 pour Application Gateway, SAP Web Dispatcher et SAP NetWeaver.

Équilibreur de charge Azure. Azure Standard Load Balancer fournit des éléments de mise en réseau pour la conception de haute disponibilité de vos systèmes SAP. Pour les systèmes en cluster, Standard Load Balancer fournit l’adresse IP virtuelle du service de cluster, comme les instances asCS/SCS et les bases de données s’exécutant sur des machines virtuelles. Vous pouvez également utiliser Standard Load Balancer pour fournir l’adresse IP du nom d’hôte SAP virtuel des systèmes qui ne sont pas en cluster lorsque les adresses IP secondaires sur les cartes réseau Azure ne sont pas une option. L’utilisation de Standard Load Balancer au lieu d’Application Gateway pour traiter l’accès Internet sortant est abordée plus loin dans cet article.

Conception du réseau

L’architecture utilise deux réseaux virtuels distoncts, les deux réseaux virtuels spoke appairés au réseau virtuel du hub central. Il n’y a pas de peering spoke-to-spoke. Dans la topologie en étoile qui est utilisée, la communication passe par le hub. La séparation des réseaux permet de protéger les applications contre les violations.

Un réseau de périmètre spécifique à l’application (également appelé DMZ) contient les applications accessibles sur Internet, telles que SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent et autres. Dans le diagramme d’architecture, le réseau de périmètre est nommé périmètre SAP - réseau virtuel spoke. En raison des dépendances sur les systèmes SAP, l’équipe SAP effectue généralement le déploiement, la configuration et la gestion de ces services. C’est pourquoi ces services de périmètre SAP ne se trouvent souvent pas dans un abonnement et un réseau hub central. Souvent, les défis organisationnels sont dus à l’emplacement hub central des applications ou des services spécifiques à la charge de travail.

Voici quelques-uns des avantages de l’utilisation d’un réseau virtuel de périmètre SAP distinct :

  • Isolation rapide et immédiate des services compromis si une violation est détectée. La suppression de l’appairage de réseaux virtuels du périmètre SAP vers le hub isole immédiatement les charges de travail de périmètre SAP et les applications de réseau virtuel d’application SAP à partir d’Internet. La modification ou la suppression d’une règle de groupe de sécurité réseau qui autorise l’accès affecte uniquement les nouvelles connexions et non pas les connexions existantes.
  • Contrôles plus stricts sur le réseau virtuel et le sous-réseau, avec un verrouillage strict sur les partenaires de communication dans et hors du réseau de périmètre SAP et des réseaux d’applications SAP. Vous pouvez étendre un contrôle accru aux utilisateurs autorisés et aux méthodes d’accès aux applications du périmètre SAP, avec différents back ends d’autorisation, accès privilégiés ou identifiants de connexion pour les applications du périmètre SAP.

Les inconvénients résident dans la complexité accrue et les coûts d’appairage de réseaux virtuels supplémentaires pour le trafic SAP lié à Internet (car la communication doit passer par l’appairage de réseaux virtuels à deux reprises). L’impact de la latence sur le trafic de peering spoke-hub-spoke dépend des pare-feu en place et doit être mesuré.

Architecture simplifiée

Pour répondre aux recommandations de cet article, mais limiter les inconvénients, vous pouvez utiliser un réseau virtuel spoke unique pour le périmètre et les applications SAP. L’architecture suivante contient tous les sous-réseaux d’un même réseau virtuel de production SAP. L’avantage de l’isolation immédiate en arrêtant l’appairage de réseaux virtuels vers le périmètre SAP s’il est compromis n’est pas disponible. Dans ce scénario, les modifications apportées aux groupes de sécurité réseau affectent uniquement les nouvelles connexions.

Diagramme montrant une architecture simplifiée pour la communication avec Internet pour SAP sur Azure.

Téléchargez un fichier Visio des architectures de cet article.

Pour les déploiements qui sont plus petits en taille et en étendue, l’architecture simplifiée peut être mieux adaptée, et elle respecte toujours les principes de l’architecture plus complexe. Sauf indication contraire, cet article fait référence à l’architecture plus complexe.

L’architecture simplifiée utilise une passerelle NAT dans le sous-réseau de périmètre SAP. Cette passerelle fournit une connectivité sortante pour SAP Cloud Connector et SAP Analytics Cloud Agent et les mises à jour du système d’exploitation pour les machines virtuelles déployées. Étant donné que SAProuter nécessite à la fois des connexions entrantes et sortantes, le chemin de communication SAProuter passe par le pare-feu au lieu d’utiliser la passerelle NAT. L’architecture simplifiée place également Application Gateway avec son propre sous-réseau désigné dans le réseau virtuel de périmètre SAP, en tant qu’approche alternative au réseau virtuel hub.

Une passerelle NAT est un service qui fournit des adresses IP publiques statiques pour la connectivité sortante. La passerelle NAT est affectée à un sous-réseau. Toutes les communications sortantes utilisent les adresses IP de la passerelle NAT pour l’accès à Internet. Les connexions entrantes n’utilisent pas la passerelle NAT. Les applications telles que SAP Cloud Connector ou les services de mise à jour du système d’exploitation de machine virtuelle qui accèdent aux référentiels sur Internet peuvent utiliser la passerelle NAT au lieu de router tout le trafic sortant via le pare-feu central. Souvent, les règles définies par l’utilisateur sont implémentées sur tous les sous-réseaux pour forcer le trafic internet de tous les réseaux virtuels via le pare-feu central.

Selon vos besoins, vous pouvez utiliser la passerelle NAT comme alternative au pare-feu central pour les connexions sortantes. En procédant ainsi, vous pouvez réduire la charge sur le pare-feu central tout en communiquant avec les points de terminaison publics autorisés par le groupe de sécurité réseau. Vous obtenez également un contrôle IP sortant, car vous pouvez configurer des règles de pare-feu de destination sur une liste d’adresses IP définies de la passerelle NAT. Par exemple, vous pouvez atteindre des points de terminaison publics Azure utilisés par des services publics, des référentiels de correctifs de système d’exploitation ou des interfaces tierces.

Pour une configuration à haute disponibilité, n’oubliez pas que la passerelle NAT est déployée dans une seule zone uniquement et n’est pas actuellement redondante interzone. Avec une passerelle NAT unique, il n’est pas idéal pour les déploiements SAP qui utilisent le déploiement interzone (interzone) pour les machines virtuelles.

Utilisation de composants réseau dans un paysage SAP

Un document d’architecture ne représente généralement qu’un seul système ou paysage SAP. Cela facilite la compréhension. Il en résulte que, souvent, la vue d’ensemble, c’est-à-dire la manière dont l’architecture s’intègre dans un paysage SAP plus vaste comprenant plusieurs voies et niveaux de système, n’est pas abordée.

Les services de mise en réseau centralisée, tels que le pare-feu, la passerelle NAT et les serveurs proxy s’ils sont déployés, sont les plus utilisés dans l’ensemble du paysage SAP de tous les niveaux : production, préproduction, développement et bac à sable. En fonction de vos besoins, de la taille de votre organisation et des stratégies métier, vous pouvez envisager des implémentations distinctes par niveau, ou un environnement de production et un environnement de bac à sable/test.

Les services qui servent généralement un système SAP sont mieux séparés, comme décrit ici :

  • Les équilibreurs de charge doivent être dédiés à des services individuels. La stratégie d’entreprise dicte le nommage et le regroupement des ressources. Nous vous recommandons d’utiliser un équilibreur de charge pour ASCS/SCS et ERS et un autre pour la base de données, séparés pour chaque SID SAP. Sinon, un équilibreur de charge unique pour les clusters (A)SCS, ERS et DB d’un système SAP est également une bonne conception. Cette configuration permet de s’assurer que la résolution des problèmes n’est pas complexe, avec plusieurs pools front-end et back-end et des règles d’équilibrage de charge sur un seul équilibreur de charge. Un équilibreur de charge unique par SID SAP garantit également que le placement dans les groupes de ressources correspond à celui d’autres composants d’infrastructure.
  • Application Gateway, comme un équilibreur de charge, autorise plusieurs back-ends, front-ends, paramètres HTTP et règles. La décision d’utiliser une passerelle d’application pour plusieurs utilisations est plus courante ici, car tous les systèmes SAP de l’environnement n’ont pas besoin d’un accès public. Dans ce contexte, plusieurs utilisations incluent différents ports de répartiteur web pour les mêmes systèmes SAP S/4HANA ou différents environnements SAP. Nous vous recommandons d’utiliser au moins une passerelle d’application par niveau (production, hors production et bac à sable) sauf si la complexité et le nombre de systèmes connectés deviennent trop élevés.
  • Les services SAP, tels que SAProuter, Cloud Connector et Analytics Cloud Agent, sont déployés en fonction des exigences de l’application, soit de manière centralisée, soit fractionnées. Il est souvent souhaité de séparé production et tests.

Dimensionnement et conception du sous-réseau

Lorsque vous concevez des sous-réseaux pour votre paysage SAP, veillez à respecter les principes de dimensionnement et de conception :

  • Plusieurs services PaaS (platform as a service) Azure nécessitent leurs propres sous-réseaux désignés.
  • Application Gateway recommande un sous-réseau /24 pour la mise à l’échelle. Si vous choisissez de limiter Application Gateway, mettre à l’échelle un sous-réseau plus petit peut être utilisé, avec un minimum /26 ou plus. Vous ne pouvez pas utiliser les deux versions de Application Gateway (1 et 2) dans le même sous-réseau.
  • Si vous utilisez Azure NetApp Files pour vos partages NFS/SMB ou votre stockage de base de données, un sous-réseau désigné est requis. Un sous-réseau /24 est la valeur par défaut. Utilisez vos exigences pour déterminer le dimensionnement approprié.
  • Si vous utilisez des noms d’hôtes virtuels SAP, vous avez besoin d’un espace d’adressage supplémentaire dans vos sous-réseaux SAP, y compris le périmètre SAP.
  • Les services centraux tels qu’Azure Bastion ou Pare-feu Azure, généralement gérés par une équipe informatique centrale, nécessitent leurs propres sous-réseaux dédiés de taille suffisante.

En utilisant des sous-réseaux dédiés pour les bases de données et les applications SAP, vous pouvez définir des groupes de sécurité réseau de façon à les rendre plus stricts, ce qui permet de protéger les deux types d’applications avec leurs propres ensembles de règles. Vous pouvez ensuite limiter l’accès aux bases de données aux applications SAP plus facilement sans avoir à recourir à des groupes de sécurité d’application pour un contrôle de sécurité ciblé. La séparation de votre application SAP et des sous-réseaux de base de données facilite également la gestion de vos règles de sécurité dans les groupes de sécurité réseau.

Services SAP

SAProuter

Vous pouvez utiliser SAProuter pour permettre à des tiers tels que le support SAP ou vos partenaires d’accéder à votre système SAP. SAProuter s’exécute sur une machine virtuelle dans Azure. Les autorisations d’itinéraire pour l’utilisation de SAProuter sont stockées dans un fichier plat appelé saprouttab. Les entrées saprouttab autorisent la connexion à partir de n’importe quel port TCP/IP vers une destination réseau derrière SAProuter, généralement vos machines virtuelles système SAP. L’accès à distance par le support SAP s’appuie sur SAProuter. L’architecture principale utilise la conception décrite précédemment, avec une machine virtuelle SAProuter exécutée dans le réseau virtuel de périmètre SAP désigné. Par le biais de l’appairage de réseaux virtuels, SAProuter communique ensuite avec vos serveurs SAP qui s’exécutent dans leur réseau virtuel spoke et leurs sous-réseaux.

SAProuter est un tunnel vers SAP ou vers vos partenaires. Cette architecture décrit l’utilisation de SAProuter avec SNC pour établir un tunnel d’application chiffré (couche réseau 7) auprès de SAP/partenaires. L’utilisation du tunnel basé sur IPSEC n’est pas couverte dans cette architecture actuellement.

Les fonctionnalités suivantes permettent de protéger le chemin de communication sur Internet :

  • Pare-feu Azure ou une appliance virtuelle réseau tierce fournit le point d’entrée IP public dans vos réseaux Azure. Les règles de pare-feu limitent la communication aux adresses IP autorisées uniquement. Pour votre connexion à la prise en charge de SAP, la note SAP 48243, « Integrating the SAProuter software into a firewall environment » (Intégration du logiciel SAProuter dans un environnement de pare-feu) fournit la liste des adresses IP des routeurs SAP.
  • Comme les règles de pare-feu, les règles de sécurité réseau autorisent la communication sur le port de SAProuter, généralement le port 3299, avec la destination désignée.
  • Vous conservez les règles d’autorisation/de refus SAProuter dans le fichier saprouttab, en spécifiant qui peut contacter SAProuter et quel système SAP est accessible.
  • D’autres règles de groupe de sécurité réseau sont en place sur les sous-réseaux respectifs du sous-réseau de production SAP qui contient les systèmes SAP.

Pour connaître les étapes de configuration de SAProuter avec Pare-feu Azure, consultez Configuration de SAProuter avec Pare-feu Azure.

Considérations liées à la sécurité de SAProuter

Étant donné que SAProuter ne fonctionne pas dans le même sous-réseau d’application que vos systèmes SAP, les mécanismes de connexion du système d’exploitation peuvent être différents. Selon vos stratégies, vous pouvez utiliser un domaine d’authentification distinct ou des informations d’identification d’utilisateur entièrement hôtes pour SAProuter. En cas de violation de la sécurité, l’accès en cascade aux systèmes SAP internes n’est pas possible en raison de la base d’informations d’identification différente. La séparation du réseau dans ce cas, comme décrit précédemment, peut dissocier un accès supplémentaire d’un SAProuter compromis dans vos sous-réseaux d’application. Vous pouvez effectuer cette isolation en déconnectant le peering de réseau virtuel de périmètre SAP.

Considérations relatives à la haute disponibilité de SaProuter

Étant donné que SAProuter est un fichier exécutable simple avec une table d’autorisations de routage basée sur un fichier, il peut être facilement démarré. L’application n’a pas de haute disponibilité intégrée. En cas d’échec d’une machine virtuelle ou d’une application, le service doit démarrer sur une autre machine virtuelle. L’utilisation d’un nom d’hôte virtuel pour le service SAProuter est idéale. Le nom d’hôte virtuel est lié à une adresse IP, qui est affectée en tant que configuration IP secondaire avec la carte réseau de la machine virtuelle ou à un équilibreur de charge interne connecté à la machine virtuelle. Dans cette configuration, si le service SAProuter doit être déplacé vers une autre machine virtuelle, la configuration IP du nom d’hôte virtuel du service peut être supprimée. Vous ajoutez ensuite le nom d’hôte virtuel sur une autre machine virtuelle sans avoir à modifier les tables de routage ou la configuration du pare-feu. Elles sont toutes configurés pour utiliser l’adresse IP virtuelle. Pour plus d’informations, consultez Utiliser des noms d’hôtes virtuels SAP avec Linux dans Azure.

SaProuters en cascade

Pour implémenter des SAProuters en cascade, vous pouvez définir jusqu’à deux SAProuters pour les connexions de prise en charge SAP. Le premier SAProuter, exécuté dans le sous-réseau d’application de périmètre SAP, fournit l’accès à partir du pare-feu central et de SAP ou de SAProuters partenaires. Les seules destinations autorisées sont d’autres SAProuters, exécutés avec des charges de travail spécifiques. Les SAProuters en cascade peuvent utiliser la séparation par niveau, par région ou par SID, selon votre architecture. Le second SAProuter accepte uniquement les connexions internes du premier SAProuter et fournit l’accès à des systèmes et machines virtuelles SAP individuels. Cette conception vous permet de séparer l’accès et la gestion entre différentes équipes si vous en avez besoin. Pour obtenir un exemple de SAProuters en cascade, consultez Configuration de SAProuter avec Pare-feu Azure.

SAP Fiori et WebGui

SAP Fiori et d’autres serveurs front-end HTTPS pour les applications SAP sont souvent utilisés en dehors du réseau d’entreprise interne. La nécessité d’être disponible sur Internet exige une solution de haute sécurité pour aider à protéger l’application SAP. Application Gateway avec Web Application Firewall est le service idéal à cet égard.

Pour les utilisateurs et les applications qui accèdent au nom d’hôte public de l’adresse IP publique liée à Application Gateway, la session HTTPS est arrêtée sur Application Gateway. Un pool principal de deux machines virtuelles SAP Web Dispatcher ou plus obtient des sessions de tourniquet (round robin) auprès d’Application Gateway. Cette passerelle d’application de trafic interne vers Web Dispatcher peut fonctionner avec HTTP ou HTTPS, selon les exigences. Avec HTTPS entre les machines virtuelles Application Gateway et Web Dispatcher, utilisez un certificat et une chaîne de certificats bien connue de l’équipe SAP pour toute rotation périodique des certificats. Le pare-feu d’applications web permet de protéger SAP Web Dispatcher contre les attaques provenant d’Internet avec l’ensemble de règles de base OWASP. SAP NetWeaver, souvent lié à Microsoft Entra ID par l’authentification unique (SSO), effectue l’authentification utilisateur. Pour connaître les étapes nécessaires à la configuration de l’authentification unique pour Fiori à l’aide d’Application Gateway, consultez Configuration de l’authentification unique à l’aide de SAML et de Microsoft Entra ID pour les URL publiques et internes.

N’oubliez pas que vous devez sécuriser sap Web Dispatcher en tout cas, même s’il est ouvert uniquement en interne, accessible via Application Gateway via une adresse IP publique ou accessible par d’autres moyens réseau. Pour plus d’informations, consultez Informations de sécurité pour SAP Web Dispatcher.

Pare-feu Azure et Application Gateway

Tout le trafic web fourni par Application Gateway est basé sur HTTPS et chiffré avec le certificat TLS fourni. Vous pouvez utiliser Pare-feu Azure comme point d’entrée du réseau d’entreprise, via son adresse IP publique, puis acheminer le trafic SAP Fiori du pare-feu vers Application Gateway via une adresse IP interne. Pour plus d’informations, consultez Application Gateway derrière un pare-feu. Étant donné que le chiffrement TCP/IP de couche 7 est déjà en place via TLS, il existe un avantage limité à l’utilisation d’un pare-feu dans ce scénario, et vous ne pouvez pas effectuer d’inspection des paquets. Fiori communique via la même adresse IP externe pour le trafic entrant et sortant, ce qui n’est généralement pas nécessaire pour les déploiements SAP Fiori.

Le déploiement en tandem d’Application Gateway et d’un pare-feu de niveau 4 présente certains avantages :

  • Intégration possible à la gestion des stratégies de sécurité à l’échelle de l’entreprise.
  • Le trafic réseau qui enfreint les règles de sécurité est déjà ignoré. Il ne nécessite donc pas d’inspection.

Ce déploiement combiné est une bonne architecture. La méthode de gestion du trafic Internet entrant dépend de votre architecture d’entreprise globale. Vous devez également prendre en compte la façon dont l’architecture réseau globale s’adapte aux méthodes d’accès à partir de l’espace d’adressage IP interne, comme les clients locaux. Cette considération est abordée dans la section suivante.

Application Gateway pour les adresses IP internes (facultatif)

Cette architecture se concentre sur les applications accessibles sur Internet. Il existe différentes options disponibles pour les clients qui accèdent à SAP Fiori, à l’interface utilisateur web d’un système SAP NetWeaver ou à une autre interface SAP HTTPS via une adresse IP privée interne. Un scénario consiste à traiter tous les accès à Fiori en tant qu’accès public, via l’adresse IP publique. Une autre option consiste à utiliser l’accès réseau direct via le réseau privé aux répartiteurs web SAP en contournant entièrement Application Gateway. Une troisième option consiste à utiliser des adresses IP privées et publiques sur Application Gateway, en fournissant l’accès à Internet et au réseau privé.

Vous pouvez utiliser une configuration similaire avec une adresse IP privée sur Application Gateway pour un accès réseau privé uniquement au paysage SAP. L’adresse IP publique dans ce cas est utilisée uniquement à des fins de gestion et n’a pas d’écouteur associé.

En guise d’alternative à l’utilisation de Application Gateway, vous pouvez utiliser un équilibreur de charge en interne. Vous pouvez utiliser un équilibreur de charge interne standard avec des machines virtuelles Web Dispatcher configurées en tant que back-end de tourniquet. Dans ce scénario, l’équilibreur de charge standard est placé avec les machines virtuelles Web Dispatcher dans le sous-réseau de l’application de production SAP et fournit un équilibrage de charge actif/actif entre les machines virtuelles Web Dispatcher.

Pour les déploiements accessibles sur Internet, nous vous recommandons d’utiliser Application Gateway avec Web Application Firewall au lieu d’un équilibreur de charge avec une adresse IP publique.

SAP Business Technology Platform (BTP)

SAP BTP est un vaste ensemble d’applications SAP, SaaS ou PaaS, généralement accessibles via un point de terminaison public via Internet. SAP Cloud Connector est souvent utilisé pour fournir une communication pour les applications s’exécutant dans des réseaux privés, comme un système SAP S/4HANA s’exécutant sur Azure. SAP Cloud Connector s’exécute en tant qu’application dans une machine virtuelle. Il nécessite un accès Internet sortant pour établir un tunnel HTTPS chiffré par TLS avec SAP BTP. Il agit comme un proxy d’appel inverse entre la plage d’adresses IP privées de votre réseau virtuel et les applications SAP BTP. En raison de cette prise en charge des appels inversés, il n’est pas nécessaire d’ouvrir des ports de pare-feu ou d’autres accès pour les connexions entrantes, car la connexion à partir de votre réseau virtuel est sortante.

Par défaut, les machines virtuelles disposent d’un accès Internet sortant en mode natif sur Azure. L’adresse IP publique utilisée pour le trafic sortant, quand aucune adresse IP publique dédiée n’est associée à la machine virtuelle, est choisie de manière aléatoire dans le pool d’adresses IP publiques de la région Azure spécifique. Vous ne pouvez pas la contrôler. Pour vous assurer que les connexions sortantes sont établies par le biais d’un service contrôlé et identifiable et d’une adresse IP, vous pouvez utiliser l’une des méthodes suivantes :

  • Passerelle NAT associée au sous-réseau ou à l’équilibreur de charge et à son adresse IP publique.
  • Serveurs proxy HTTP que vous utilisez.
  • Itinéraire défini par l’utilisateur qui force le trafic réseau à circuler vers une appliance réseau comme un pare-feu.

Le diagramme d’architecture illustre le scénario le plus courant : routage du trafic internet vers le réseau virtuel hub et via le pare-feu central. Vous devez configurer d’autres paramètres dans SAP Cloud Connector pour vous connecter à votre compte SAP BTP.

Haute disponibilité pour SAP Cloud Connector

La haute disponibilité est intégrée à SAP Cloud Connector. Cloud Connector est installé sur deux machines virtuelles. L’instance principale est active et l’instance fantôme est connectée à celle-ci. Elles partagent la configuration et sont synchronisés en mode natif. Si l’instance principale n’est pas disponible, la machine virtuelle secondaire tente de prendre le rôle principal et de rétablir le tunnel TLS vers SAP BTP. Un environnement Cloud Connector à haute disponibilité s’affiche dans l’architecture. Pour la configuration, vous n’avez pas besoin d’autres technologies Azure, comme un équilibreur de charge ou un logiciel de cluster. Pour plus d’informations sur la configuration et l’opération, consultez la documentation SAP.

SAP Analytics Cloud Agent

Pour certains scénarios d’application, SAP Analytics Cloud Agent est une application installée dans une machine virtuelle. Elle utilise SAP Cloud Connector pour la connectivité SAP BTP. Dans cette architecture, la machine virtuelle SAP Analytics Cloud Agent s’exécute dans le sous-réseau de l’application de périmètre SAP en même temps que les machines virtuelles SAP Cloud Connector. Pour connaître le flux de trafic à partir de réseaux privés tels qu’un réseau virtuel Azure vers SAP BTP via SAP Analytics Cloud Agent, consultez la documentation SAP.

SAP fournit le service Private Link pour SAP BTP. Cela active les connexions privées entre les services SAP BTP sélectionnés et les services sélectionnés dans votre abonnement Azure et votre réseau virtuel. Lorsque vous utilisez Private Link service, la communication n’est pas acheminée via l’Internet public. Elle demeure sur la dorsale du réseau mondial Azure, hautement sécurisé. La communication avec les services Azure se produit via un espace d’adressage privé. La protection améliorée de l’exfiltration des données est intégrée lorsque vous utilisez Private Link service, car le point de terminaison privé mappe le service Azure spécifique à une adresse IP. L’accès est limité au service Azure mappé.

Pour certains scénarios d’intégration SAP BTP, l’approche du service Private Link est recommandée. Pour d’autres, SAP Cloud Connector est préférable. Pour plus d’informations sur la décision à utiliser, consultez Exécution de Cloud Connector et de SAP Private Link côte à côte.

SAP RISE/ECS

Si SAP exploite votre système SAP sous un contrat SAP RISE/ECS, SAP est le partenaire de service géré. L’environnement SAP est déployé par SAP. Sur l’architecture de SAP, l’architecture présentée ici ne s’applique pas à vos systèmes qui s’exécutent dans RISE avec SAP/ECS. Pour plus d’informations sur l’intégration de ce type de paysage SAP aux services Azure et à votre réseau, consultez la documentation Azure.

Autres exigences en matière de communication SAP

Des considérations supplémentaires concernant les communications liées à Internet peuvent s’appliquer à un paysage SAP fonctionnant sur Azure. Le flux de trafic dans cette architecture utilise un pare-feu Azure central pour ce trafic sortant. Les règles définies par l’utilisateur dans les réseaux virtuels spoke acheminent les demandes de trafic internet vers le pare-feu. Vous pouvez également utiliser des passerelles NAT sur des sous-réseaux spécifiques, une communication sortante Azure par défaut, des adresses IP publiques sur des machines virtuelles (non recommandées) ou un équilibreur de charge public avec des règles de trafic sortant. Les scénarios classiques atteignent des points de terminaison publics de l’ID Microsoft Entra, des API de gestion Azure à management.azure.com et des services d’applications tierces ou d’applications gouvernementales via l’accès réseau sortant.

En raison des modifications apportées à l’accès sortant par défaut dans Azure, vérifiez qu’un accès sortant évolutif est défini. Pour les machines virtuelles qui se trouvent derrière un équilibreur de charge interne standard, comme celles des environnements en cluster, gardez à l’esprit que Standard Load Balancer modifie le comportement de la connectivité publique. Pour plus d’informations, consultez Connectivité de point de terminaison public pour les machines virtuelles à l’aide d’Azure Standard Load Balancer dans les scénarios de haute disponibilité SAP.

Pour plus d’informations sur la connectivité sortante par défaut à partir de machines virtuelles, consultez les options de routage des machines virtuelles à partir de sous-réseaux privés sur le blog Réseau Azure.

Mises à jour de système d’exploitation

Les mises à jour du système d’exploitation se trouvent souvent derrière un point de terminaison public et sont accessibles via Internet. Si aucun référentiel d’entreprise et aucune gestion des mises à jour n’est en place, la mise en miroir des mises à jour du système d’exploitation des fournisseurs sur des adresses IP privées/machines virtuelles, votre charge de travail SAP doit accéder aux référentiels de mise à jour des fournisseurs.

Pour les systèmes d’exploitation Linux, vous pouvez accéder aux référentiels suivants si vous obtenez la licence du système d’exploitation auprès d’Azure. Si vous achetez des licences directement et que vous les apportez à Azure (BYOS), contactez le fournisseur du système d’exploitation pour savoir comment se connecter aux référentiels de système d’exploitation et à leurs plages d’adresses IP respectives.

Gestion des clusters à haute disponibilité

Les systèmes hautement disponibles tels que SAP ASCS/SCS en cluster ou les bases de données peuvent utiliser un gestionnaire de cluster avec l’agent de clôture Azure en tant qu’appareil STONITH. Ces systèmes dépendent de l’accès à Azure Resource Manager. Resource Manager est utilisé pour les requêtes d’état sur les ressources Azure et pour les opérations pour arrêter et démarrer des machines virtuelles. Étant donné que Resource Manager est un point de terminaison public, disponible sous management.azure.com, la communication sortante de machine virtuelle doit être en mesure de l’atteindre. Cette architecture s’appuie sur un pare-feu central avec des règles définies par l’utilisateur qui acheminent le trafic à partir de réseaux virtuels SAP. Pour connaître les alternatives, consultez les sections précédentes.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Autre contributeur :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Communautés

Envisagez d’utiliser ces communautés pour obtenir des réponses aux questions et pour obtenir de l’aide sur la configuration d’un déploiement :

Étapes suivantes