L’objectif de ce billet de blog est de présenter la publication d’une application Web avec Azure Application Proxy.
Azure Application Proxy est un service cloud destiné à faciliter la publication d’applications « on premise » sur Internet tout en apportant de la sécurité.
A titre de démonstration, nous disposons d’un environnement « Intranet » constitué de :
- Active Directory
- Une application Web configurée pour de l’authentification LDAP ou LDAPs
- Un PC utilisé pour accéder à l’application Web en http ou https
L’utilisation interne se fait par accès http sur le serveur Web, l’authentification est transmise en LDAPs au contrôleur de domaine :
Une fois la page d’accueil chargée, une authentification est demandée. Cette authentification est retransmise via LDAPs sur le contrôleur de domaine :
La publication traditionnelle de ce type d’application nécessite la mise en place d’un reverse proxy dans une DMZ avec une gestion rigoureuse des flux entrants dont dépend en partie la sécurité.
Il est nécessaire de gérer :
- Les flux entrants externes
- Les flux entrants entre la DMZ et l’Intranet
La publication se fait généralement en https, les reverse proxy étant capables de reformuler les demandes en http vis-à-vis des applications ne prenant pas en charge https :
Le service Azure APP Proxy offre un mécanisme de publication totalement différent, permettant de s’affranchir des DMZ ainsi que des reverse proxy tout en maintenant un niveau de sécurité élevé.
Il s’agit d’un service hébergé dans le Cloud AZURE, constitué essentiellement de :
- Points de terminaison Azure APP Proxy (hébergés dans le Cloud)
- Connecteurs APP Proxy (déployés on premise)
Le principe consiste à traiter les demandes entrantes sur les points de terminaison du service APP Proxy et à les retransmettre au serveur Web internes par l’intermédiaire d’un ou plusieurs connecteurs APP Proxy.
Dans ce contexte, il n’y a aucun flux entrant à traiter, tout est géré par les connecteurs qui fonctionnent en flux sortant SSL et « dépilent » les demandes entrantes sur les points de terminaison APP Proxy avant d’agir eux-mêmes en tant que Proxy inverse
Ces informations sont précisées sur le site de Microsoft, ou il est clairement exprimé que les connections sont sortantes uniquement :
https://docs.microsoft.com/fr-fr/azure/active-directory/manage-apps/application-proxy-security
Filtrage de flux sortants
| Note ! Toutes les communications se produisent sur le protocole SSL et proviennent du connecteur vers le service de proxy d’application. Le service est uniquement sortant. |
La communication entre les connecteurs et le service APP Proxy se fait en https mais la vérification de la CRL se fait en http
| Numéro de port | Utilisation |
| 80 | Téléchargement de la liste de révocation de certificats lors de la validation du certificat SSL |
| 443 | Toutes les communications sortantes avec le service de proxy d’application |
Filtrage d’URL sortantes
Seules les URL suivantes sont utilisées par le service APP Proxy
| URL | Utilisation |
| *.msappproxy.net *.servicebus.windows.net |
Communication entre le connecteur et le service cloud Proxy d’application |
| mscrl.microsoft.com:80 crl.microsoft.com:80 ocsp.msocsp.com:80 www.microsoft.com:80 |
Azure utilise ces URL pour vérifier les certificats. |
| login.windows.net secure.aadcdn.microsoftonline-p.com *.microsoftonline.com *.microsoftonline-p.com *.msauth.net *.msauthimages.net *.msecnd.net *.msftauth.net *.msftauthimages.net *.phonefactor.net enterpriseregistration.windows.net management.azure.com policykeyservice.dc.ad.msft.net ctdl.windowsupdate.com:80 |
Le connecteur utilise ces URL lors du processus d’inscription. |
Vous pouvez autoriser les connexions à *.msappproxy.net et *.servicebus.windows.net si votre pare-feu ou proxy vous permet de configurer la mise en liste verte de DNS. Si ce n’est pas le cas, vous devez autoriser l’accès aux Plages d’adresses IP et étiquettes des services Azure – Cloud public. Ces dernières sont mises à jour chaque semaine.
Publication de l’application
La publication d’une application Web par APP Proxy nécessite avant tout une souscription Azure AD Premium (P1 ou P2).
Il est nécessaire de déployer un ou plusieurs connecteurs. Les binaires de déploiement du connecteur sont disponibles sur le portail Azure :
- Azure AD / Applications d’entreprise / Proxy d’application
L’installation du connecteur peut être faite sur une machine jointe à un domaine Active Directory ou non. Cependant la publication d’applications reposant sur l’authentification Windows intégrée (IWA) nécessite une machine jointe au domaine ainsi que la délégation Kerberos contrainte pour le comptes des utilisateurs vis-à-vis des applications publiées.
L’installation du connecteur transite par le Cloud Microsoft (enregistrement du connecteur sur la plateforme Azure) et nécessite de désactiver la sécurisation renforcée d’Internet Explorer (qui peut être réactivée après) :
Après installation du connecteur « on premise », il est présenté comme « Actif » dans le portail Azure :
Il reste à publier l’application depuis le portail Azure :
Azure Active Directory / Applications d’entreprise / Nouvelle Application
Il s’agit d’une « Application locale » (présente sur l’Intranet)
Il faut indiquer le nom convivial, l’URL interne, l’URL externe (à choisir parmi les domaines validés dans le tenant) et choisir si l’accès est soumis à une pré-authentification Azure AD :
Si l’URL externe est associée à un nom de domaine personalisé, il faudra uploader le certificat SSL correspondant (fichier .PFX), dans le cas contraire, le certificat est celui de Microsoft (msappproxy.net) et il n’y a rien à faire.
La pré authentification Azure AD étant choisie, il faut également choisir si l’application est accessible :
- De façon restreinte (sélection des personnes ou des groupes)
- A tous les utilisateurs authentifiés
Lorsque l’accès est restreint, il faut sélectionner les utilisateurs ou les groupes autorisés à accéder à l’application :
On peut alors accéder à l’application par son lien public
Si l’on est pas déjà authentifié Azure AD, l’accès à l’URL de l’application (https:// https://gestsup-dentan.msappproxy.net/ dans notre cas) redirige vers la pré authentification Azure AD :
L’authentification Azure AD est nécessaire, et si c’est en place, les règles d’accès conditionnel seront appliquées (MFA par exemple)
On accède à l’application telle qu’elle est vue depuis l’intranet :
L’authentification LDAPS est relayée au contrôleur de domaine et l’application est accessible :
Si l’utilisateur authentifié à Azure n’a pas le droit d’accéder à l’application, il est bloqué :
Les accès étant soumis à une pré authentification Azure AD, tous les accès sont consignés dans les logs Azure, et consultables depuis le portail Azure AD
On y trouve l’heure d’accès, le nom de la personne, le statut (réussite / échec) l’IP et l’emplacement ainsi que l’accès conditionnel le cas échéant :
La publication d’une application dans ce contexte est une opération assez simple à réaliser. Selon la complexité des applications (méthodes d’authentification) cela peut s’avérer plus complexe mais cette solution mérite largement d’être évaluée avant de choisir d’autres méthodes de publication.
Notons enfin que la pré authentification Azure AD est vraiment intéressante puisqu’elle embarque tous les mécanismes de sécurité liés à Azure AD Premium :
- Accès conditionnel (appartenance à des groupes, accès depuis un site particulier, calcul du facteur de risque, types et état des périphériques …)
- Authentification Multi Facteur
- Reporting
- ….
Bonnes publications et merci de votre lecture