Create a Real-time Protection Policy for Private Apps

Private apps are not steered by default, which means by default private applications are never accessible to end-users, and they also will not receive a user notification about this. The end-user’s steering profile needs to be updated to include the private apps required for the User (Group/OU), and a matching real-time policy must exist if no discovery is configured for the user. Policies are required to log events and enable access to Users, Groups, or OUs. 

Use Real-time Protection policies to:

• Grant access to a private app for users, groups, or OUs, based on Operating System, Access Method and/or Device Classification.
• Block access and notify the user(s) why access is denied.
• Block access but provide instructions to gain access, such as contacting IT or upgrading a device.
• Use a DLP profile with Access Method: Browser Access to get Netskope Events, Alerts, and DLP Incidents data for private apps. To apply DLP for Browser Access Private Apps, refer to Enforce DLP for NPA Browser Access Private Apps.

For a specific private app, you may want to have one policy that grants access for a defined set of users, and then use a second policy that blocks and notifies users who don’t have access.

To create a Real-time Protection policy for private apps, use the allow or block methods explained below.

1. Go to Policies > Real-time Protection.
2. Click New policy and select Private App Access.
3. For Source:
   • Specify the Users, OU, or Groups for which you want to allow/block access to the Private App(s) (otherwise Any user is valid).
   • Specify whether the Access Method is Browser Access or Client (A DLP Profile can only be assigned to Browser Access).
     For policies with Browser Access Applications, you can also configure Source IP criteria. This enhances security by allowing administrators to restrict (allow or block) access to private applications based on the source (egress) IP of the end-users. 
     Note that Source IP criteria for Browser Access is currently controlled by a feature flag. Please contact your Netskope account team to enable this feature.

     Note

     When this feature for Source IP Criteria is enabled for a tenant, the Source IP criteria become available within the policy for Private Apps. While the Source IP criteria will be visible for both Client and Browser Access in the UI, it will currently only apply to Browser Access based applications.

   • Which Operating System the user is allowed/blocked to use (Only valid with access method Client).
   • Which Custom Device Classification profile must be active for the user for the rule to apply (Only valid with access method Client. Browser Access will by default not have any Custom Device Classification and will never hit the Policy as it’s seen as a Unmanaged device).
4. For Destination:
   • Either choose the Private App(s) or Private App Tag from the dropdown list.
   • Select the Activities that the destination rule is applied to (Only valid with Browser Access).
5. For Action, select Allow to grant access. To deny access, select Block, select a policy notification template from the dropdown list, or create one.
6. Give the policy a name, and then click Save.
7. Click Apply Changes.

• Create a Policy User Notification