Microsoft Entra Private Access License
You assign a microsoft entra private access license to users in your identity portal. Then you link local connectors to route traffic to private apps without a VPN. Teams often start by mapping broad network segments to user groups. This fast setup helps people work from anywhere right away. Still, broad group rules often grant way too much network reach. One user might reach ten databases when they only need one. How the microsoft entra private access license works This license replaces old
Microsoft Entra ID (Azure AD) + Virtual Private Database: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You assign a microsoft entra private access license to users in your identity portal. Then you link local connectors to route traffic to private apps without a VPN. Teams often start by mapping broad network segments to user groups. This fast setup helps people work from anywhere right away. Still, broad group rules often grant way too much network reach. One user might reach ten databases when they only need one.
How the microsoft entra private access license works
This license replaces old network tunnels with identity-based routing rules. First, an admin installs small software connectors inside the private network. These connectors sit near the private servers and databases. They make outbound calls to the cloud service and wait for traffic. You do not need to open inbound firewall ports for them.
Next, the team sets up private app definitions in the cloud portal. Each definition lists specific private IP addresses, hostnames, and TCP or UDP ports. Admins then assign these private apps to specific user groups. They also link conditional check rules to those same app assignments. These rules check user identity and device health before traffic can flow.
On the user side, each worker runs a local client agent. This agent watches for requests to those private IP addresses or hostnames. When a developer opens a database tool, the agent catches the network packets. It sends the request to the cloud service for a rule check. If the user has the right license and passes the check, traffic flows. The cloud service connects the user agent to the private connector.
Why network routing rules are not enough
This setup solves a major problem for modern security teams. It stops bad actors from scanning the whole internal network after logging in. You no longer put remote laptops directly on the office network. The setup checks who can open a port on a target host. It also logs which user opened a network tunnel and when.
Yet a big security gap keeps the session active after the port opens. Network routing tools only understand IP addresses, ports, and user groups. They do not read the database queries or shell commands inside the tunnel. Once a developer connects to the configured port, the network tool steps back. The user must still log in to the database with a local password.
Microsoft Entra ID (Azure AD) + Virtual Private Database: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Teams often share these database passwords so people can get work done. If five engineers share one admin login, your audit logs lose value. The network log shows five people opened the configured port that morning. The database log shows the shared admin account dropped a production table. You cannot tell which person actually ran the bad command. Also, the network tunnel cannot rewrite sensitive data like emails or card numbers. Every query result comes back to the laptop in plain text.
Scoping permissions down to the action level
To reduce risk, teams should narrow their network rules as much as possible. Do not publish a whole subnet when a team only needs one server. Split your private app definitions by single host and single port. Map each narrow rule to a small group of users who need it.
Even with tight port rules, you must still manage what happens inside the session. Network licenses control the path to the door, not what happens inside the room. Security teams need visibility into the exact queries and commands users run. You also need controls that act on data before it reaches the user.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Does a microsoft entra private access license replace database passwords?
No, it only controls network routing to the database port. Users still need a valid database username and password to log in and run queries.
Can this license block a user from dropping a database table?
No, the license works at the network transport layer. Once it opens the TCP port, it cannot inspect or block specific SQL statements inside the traffic.
What happens if an admin assigns a whole subnet to a user group?
Every user in that group can reach all IP addresses and allowed ports in that subnet. This creates broad lateral movement risk if a laptop gets compromised.