Microsoft Entra Global Secure Access

Microsoft Entra Global Secure Access (GSA) is the Microsoft implementation of a Security Service Edge (SSE) solution. SSE is a Gartner-defined category that converges network security functions—such as Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), Zero Trust Network Access (ZTNA), and Firewall as a Service (FWaaS)—into a single, cloud-delivered service. GSA extends Microsoft Entra’s identity and access management capabilities to the network layer, enabling organizations to enforce security policies at the point of connection to any application, whether hosted in Microsoft 365, other SaaS, or private data centers.

Traditional network security relies on a perimeter model: users connect to a corporate network via VPN, and then all traffic is backhauled through a central firewall. This model has several problems: - Latency: Traffic tromboning through a central data center increases delay. - Complexity: VPNs require on-premises hardware and complex routing. - Inconsistent security: Remote users bypass corporate security when accessing cloud apps directly. - No identity awareness: Traditional firewalls see IP addresses, not user identity.

GSA solves these by shifting security to the cloud edge. It uses Microsoft’s global network of over 200 edge nodes to inspect traffic close to the user, applies identity and device context, and forwards only allowed traffic to destinations.

GSA operates as a reverse proxy and forward proxy combined. The key components are: - Microsoft Entra Internet Access: Handles traffic to SaaS applications (e.g., Microsoft 365, Salesforce, Dropbox). It provides SWG capabilities, including URL filtering, TLS inspection, and threat protection. - Microsoft Entra Private Access: Handles traffic to private corporate resources (e.g., on-premises apps, Azure VMs). It uses ZTNA principles: users connect to a connector agent that establishes outbound-only tunnels, eliminating the need for inbound VPN ports.

Configuration is primarily done via the Microsoft Entra admin center or Microsoft Graph API. There is no CLI for day-to-day management, but you can use PowerShell with the Microsoft Graph module.

Example: Enable Global Secure Access using Microsoft Graph PowerShell

Connect-MgGraph -Scopes "NetworkAccess.ReadWrite.All"

# Create a traffic forwarding profile
$params = @{
  "@odata.type" = "#microsoft.graph.networkaccess.trafficForwardingProfile"
  displayName = "All Traffic"
  description = "Forward all internet and private traffic"
  trafficForwardingType = "internetPrivate"
  isEnabled = $true
}
New-MgNetworkAccessForwardingProfile -BodyParameter $params

Verification: Check tunnel status in the client:

GSA requires one of the following licenses:

Without these licenses, GSA features are not available.

A global consulting firm with 10,000 remote employees uses GSA to replace its legacy VPN. Previously, users connected to a VPN concentrator in the US headquarters, causing high latency for employees in Europe and Asia. With GSA, each user connects to the nearest Microsoft edge node (e.g., in London, Frankfurt, Singapore). Traffic to Microsoft 365 is optimized using Microsoft’s backbone, reducing latency by 30-50%. The firm configures a traffic forwarding profile to send all internet traffic through GSA, enabling URL filtering to block malicious sites. They enforce conditional access requiring MFA and device compliance. The main challenge was deploying the client to all devices; they used Intune to push the client silently. Performance is monitored via the Global Secure Access dashboard, which shows tunnel health, traffic volumes, and blocked requests. When misconfigured—for example, if the forwarding profile accidentally excludes critical IP ranges—users lose access to internal apps. The fix is to review the profile in the admin center and add the missing ranges.

A healthcare organization with 5,000 users needs to provide access to an electronic health records (EHR) system hosted on-premises. They cannot expose the EHR to the internet due to compliance (HIPAA). They deploy GSA Private Access with two connector agents on Windows Server VMs in the data center. The connectors register with Microsoft Entra ID and establish outbound-only tunnels to Microsoft edge nodes. Users install the GSA client on their laptops. When a user accesses the EHR via a specific FQDN or IP, the client tunnels traffic to the edge node, which forwards it to one of the connectors. The connector forwards the request to the EHR server. The server sees the connector’s IP, not the user’s, preserving network segmentation. Conditional access policies require that the user’s device is compliant (e.g., antivirus enabled, disk encrypted) and that access is from a trusted location. The organization uses the GSA logs in Microsoft 365 Defender to audit access. A common issue is connector overload: if only one connector is deployed, it may become saturated. Microsoft recommends at least two connectors, each supporting up to 500 concurrent connections. They also set up health monitoring alerts for connector status.

A multinational manufacturing company with 20,000 users uses both Microsoft 365 and custom SaaS apps (e.g., Salesforce, Workday) plus legacy on-premises apps. They deploy GSA with both Internet Access and Private Access. They create a unified forwarding profile that sends all traffic to Microsoft edge nodes. Internet traffic is inspected by the SWG for URL filtering and malware blocking. Private traffic is tunneled to connectors in each regional data center. They integrate with Defender for Cloud Apps to monitor user sessions and apply DLP policies (e.g., preventing upload of sensitive data to personal cloud storage). The company uses Microsoft Sentinel to correlate GSA logs with other security events. Performance considerations: they enable TLS inspection for outbound traffic, which requires deploying a trusted root certificate to all devices via Group Policy. Without this, TLS inspection fails and users see certificate errors. They also configure split tunneling to allow direct access to trusted sites like Windows Update to reduce latency. The deployment took three months, including pilot testing with 500 users. The biggest lesson was to carefully plan the forwarding profile to avoid breaking non-web applications that use non-standard ports.