7.0 Working With Access Policies

For any privileged access management product, defined policies or rules determines how various privileges are accessed across the enterprise. NetIQ Privileged Access Manager provides a method of creating policies to enable the granular control of privilege access.

Before you configure a policy, you must consider the following points:

  • Privilege access is required for multiple resources having similar privilege access and security requirements, their usage, locations, criticality to business, and other factors.

  • There are users across the organization who require different privileges across different systems. These users can be individuals such as, particular system administrator, or might be a group of users like contract employees, and Helpdesk administrators.

You can create policies in two ways:

  • Access Control: This is the latest and recommended way to define policies and steps. For more information, see Section 7.1, Access Control.

  • Command Control: Using this capability, you can create a flexible set of policies. The granular hierarchy of policies enables you to define as many policies as possible in a tree manner. You can edit any policy to grant or deny access to a user, host, and command. For more information, see Section 7.2, Command Control.

Enabling or Disabling the Policy Engine

You can either use Command Control or Access Control based on the relevance and the environment. You can enable or disable either Command Control or Access Control policy engine, by going to Settings > > Server Settings > Policy Engine. Use the slider to enable the status of the Access Control Engine or the Command Control Engine.

NOTE:The Command Control policy engine is enabled by default. If you disable both Access Control and Command Control engines, then no privileged access request is processed by either of the policy engines. Only emergency access requests will be evaluated.

Some key differences in capabilities of Access Control and Command Control in Privileged Access Manager are mentioned in the following table:

Capability

Access Control

Command Control

Structure of Policy set

  • Linear

  • Hierarchical

Defining Host/Resources

  • Resource Pools

  • Type defined

  • Brows-able Agents/Vaults

  • Host Groups

  • Heterogeneous

  • Non-Brows-able Agents/Vaults

Defining Users/Groups

  • Based on Resource Pool type

  • Type defined permissions

  • Relevant attributes for each permission

  • Generic definition for all policies

Defining Policies

  • User Roles

  • Based on authentication source

  • Brows-able authentication source

  • Generic definition for all policies

Block Access

  • By Exceptions

  • Configurable for All or Target Resources and Permissions

  • Configurable with a variety of auto-expire options

  • By Blocked Users Group

  • User is blocked from All Access

  • No expiry. Remove users from this group to reinstate access

User Experience/ UI

  • Wizard based

  • Modern User Interface

  • No guided workflows

  • Legacy User Interface

REST API

  • Standard REST API for all Objects

  • Simple APIs to add/update policies

  • Partial Coverage

  • Complex to update / re-order policies

Privilege Governance

  • Through REST APIs

  • No straight forward way to derive this information

AA/RADIUS support

  • Supported in Privileged Access Manager 4.1 and later releases

  • Supported in Privileged Access Manager 4.0 and later releases

IDM Driver support

  • Through the REST driver

  • Through the standard driver

Policy Templates

  • Not supported

  • Supported in Privileged Access Manager 4.0 and later releases