Restrict Service Connection Access Based on User Group?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

Restrict Service Connection Access Based on User Group?

L0 Member

Hello,

 

I have a quick question that I haven't been able to find a definitive answer to.  

Background:
My users are 100% remote.  We have a Prisma SASE instance that we use for remote user access.  In this SASE instance, we have a service connection that connects to our Azure tenant via Azure Virtual Network Gateway.  We currently have 3 vNets that everyone can access in a "hub and spoke" formation (one central vNet with the VNG, the 2 spoke vNets each paired with only the hub vNet.

 

We have a need to add a 3rd vNet "spoke" for another division of our company that we want to keep separate from a subset of our mobile user population.  Is there a way to configure Prisma SASE in such a way to only allow access to the "hub" vnet and the new "spoke" vNet based on criteria like username?  We are using Azure Active Directory for VPN authentication, and have tied in Azure AD into Cloud Identity Engine for username and group membership information.

1 REPLY 1

L1 Bithead

@JMay21 

First of all, security policies cannot be applied to Service Connection, so these controls must be applied at the Mobile Users' Gateway.
Since the authentication of Mobile Users means that Azure AD is used, the users who are allowed to access resources in each VNet are controlled using Security Groups in Azure AD. In addition, the destination VNet would need to be divided by network address and designated as a destination in a security rule. Specifically, I would take the following steps.

1. create a group in Azure AD with the unit to which you want to restrict access to resources (e.g., Unit-X, Division-Y)

2. configure a network address for each VNet unit (e.g. X-VNet-192.168.0.0_24)

3. create rules such as the following (these are only minimum parameters; destinations and services should be limited to the minimum necessary to mitigate security threats) All rules to VNet that were not previously restricted should also be reviewed.
Src Zone: trust
Src User: Unit-X
Dst Zone: trust
Dst Address: X-VNet-192.168.0.0_24
Action: allow

4. communication from Mobile Users to Service Connection that does not match 3 above will be denied by matching the interzone-default rule, but since it is not logged by default, it is recommended that logging be enabled.

5. In addition, you may want to include the following rule for communications between terminals connected by GlobalProtect, if you do not need to allow them. This is effective in preventing lateral movement  between terminals. Without this rule, the default is to match the intrazone-default rule and allow communication without logging.
Src Zone: trust
Src User: GlobalProtect-IP-Pool
Dst Zone: trust
Dst Address: GlobalProtect-IP-Pool
Action: deny

  • 503 Views
  • 1 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!