SASE : c’est quoi, et quelle est la réponse de Microsoft ?

• SASE est une approche qui réunit réseau + sécurité dans le cloud pour sécuriser l’accès aux applications, partout.
• Microsoft répond surtout par une approche SSE “identity-first” via Microsoft Entra Internet Access (SWG) + Microsoft Entra Private Access (ZTNA) + Defender for Cloud Apps (CASB).
• Ces briques sont regroupées sous Global Secure Access dans Entra.

1) Le problème : pourquoi tout le monde parle de SASE ?

Avant, la sécurité réseau était simple : un bureau, un datacenter, un pare-feu, et tout le monde “à l’intérieur”.

Aujourd’hui, les utilisateurs sont partout, les applications sont souvent en SaaS, et les flux ne passent plus naturellement par un périmètre unique.

Résultat : beaucoup d’organisations se retrouvent avec un mélange de VPN, proxies, filtres web, contrôles cloud et règles d’accès… mais en silos.
Et le “réflexe VPN” (ramener tout le trafic au siège) peut dégrader l’expérience et affaiblir la posture, surtout quand les outils ne partagent pas la même logique de politique.

2) SASE vs SSE : deux mots, une idée simple

Commençons par démystifier.

SASE (Secure Access Service Edge)

SASE décrit une façon moderne de livrer réseau + sécurité via un service cloud unifié (ou parfois via deux fournisseurs).

L’idée : rapprocher la sécurité “du bord” (près de l’utilisateur) au lieu de forcer le trafic à repasser par le datacenter.

SASE regroupe typiquement :

• SD‑WAN (côté réseau),
• SWG (Secure Web Gateway),
• ZTNA (Zero Trust Network Access), et souvent CASB + FWaaS selon les modèles.

SSE (Security Service Edge)

SSE représente la partie “sécurité d’accès” : protéger l’accès au web, au SaaS et aux applications privées, peu importe où se trouve l’utilisateur.

Donc, règle simple : SSE = la sécurité, SASE = SSE + le réseau (souvent SD‑WAN).

3) La réponse de Microsoft : “SSE d’abord”, pilotée par l’identité

Microsoft a structuré sa réponse autour d’une idée forte : mettre l’identité au centre et utiliser Conditional Access comme moteur de politiques (qui a accès, depuis quel appareil, avec quel niveau de risque, etc.).

Traduction simple : au lieu de gérer des règles “réseau” séparées des règles “identité”, l’objectif est que tes décisions de sécurité partent d’abord de : qui est l’utilisateur + état du device + contexte + risque.

4) Les 3 briques Microsoft à connaître (en langage humain)

4.1 Entra Internet Access = un SWG centré identité

Entra Internet Access se positionne comme un Secure Web Gateway pour protéger l’accès à internet, au SaaS et à Microsoft 365, avec des contrôles basés sur l’identité et le contexte.

Le point clé : étendre Conditional Access à des scénarios “web / réseau”, pas seulement aux applications.

Image mentale : un “portique de sécurité” cloud pour la navigation et l’accès SaaS, mais qui connaît déjà tes utilisateurs et tes politiques.

4.2 Entra Private Access = du ZTNA pour remplacer des scénarios VPN

Entra Private Access se positionne comme une solution Zero Trust Network Access pour sécuriser l’accès aux applications privées (hybride, multi-cloud), tout en réduisant certains usages du VPN.

L’objectif : un accès granulaire par application, au lieu d’ouvrir un accès large à un réseau interne.

Image mentale : au lieu de donner une “clé du bâtiment” (VPN), tu donnes un “badge” qui ouvre une porte précise (l’application X), avec contrôle continu.

4.3 Defender for Cloud Apps = le CASB dans l’ensemble

Microsoft intègre aussi un CASB (Cloud Access Security Broker) via Defender for Cloud Apps, qui complète l’ensemble côté gouvernance et contrôle des usages SaaS.

5) Global Secure Access : la “console” qui regroupe tout

Dans l’administration Entra, Global Secure Access sert de regroupement pour gérer Internet Access et Private Access au même endroit.

On y retrouve notamment :

• un client (sur les postes),
• des options de connectivité pour certains scénarios réseau,
• et des mécanismes de traffic forwarding (rediriger certains flux à travers le service).

En clair : l’idée est de simplifier l’adoption en réduisant l’empilement de consoles et de règles dispersées.

6) Et le “SASE complet” dans tout ça ?

SASE inclut aussi la partie réseau (souvent SD‑WAN).
Microsoft met surtout l’accent sur SSE (la partie sécurité), et s’inscrit dans une logique où l’architecture SASE peut être complétée selon le contexte (plateforme unique ou approche à deux fournisseurs).

Conclusion pratique :

• Microsoft propose une SSE solide, centrée identité,
• et elle s’intègre dans une stratégie SASE plus large, selon ce que tu fais pour le SD‑WAN et la connectivité.

7) Trois cas d’usage faciles à comprendre (et à vendre en interne)

Cas 1 — “On veut sécuriser l’accès au web et au SaaS sans multiplier les outils”

Objectif : passer de politiques “par IP et appliances” à des politiques “par utilisateur + device + risque”, avec une protection web/SaaS cohérente.

Cas 2 — “On veut réduire le VPN”

Objectif : remplacer certains scénarios VPN par un accès par application, plus ciblé et plus contrôlable (ZTNA).

Cas 3 — “On veut centraliser l’opérationnel”

Objectif : gérer les scénarios Internet Access / Private Access dans une même logique, avec un déploiement client et une redirection de trafic maîtrisée.

8) Conclusion

SASE est une architecture, pas un produit : l’objectif est de réunir réseau + sécurité dans le cloud, au plus près de l’utilisateur.

La réponse de Microsoft met surtout l’accent sur SSE, avec un ensemble cohérent SWG + ZTNA + CASB, piloté par l’identité (Entra) et regroupé sous Global Secure Access.

Si ton organisation est déjà très “Microsoft” (identité, politiques d’accès, endpoints), c’est une trajectoire logique : tu capitalises sur l’identité comme moteur de décision, et tu construis ton SASE autour.