Privileged Access

Introduction

Privileged access allows users to perform activities that a typical user cannot. Privileged access usually refers to highly-elevated access rights, often referring to administrative or superuser access. Quite naturally, privileged access poses a significant risk for organizations, therefore special means are in place to track privileged access.

Implementation

MidPoint features allows tracking of privileged access, tracking (application) roles that provide privileged access, as well as users that have these roles.

Privileged access tracking is built as a combination of several midPoint features. It starts with Privileged access classification. The Privileged access classification is a pre-configured object (initial objects), provided in default midPoint configuration in a ready-to-use form. The Privileged access classification is meant to be assigned to application roles that provide privileged access to applications. Application roles corresponding to administrative and superuser entitlements are obvious candidates for Privileged access classification.

In XML form:

Privileged access classification assigned to application role

<role>
    <name>CRM: Customer database admin</name>
    ...
    <assignment>
        <targetRef oid="00000000-0000-0000-0000-000000000332" type="PolicyType"/>
    </assignment>
    ...
</role>

<policy oid="00000000-0000-0000-0000-000000000332">
    <name>Privileged access</name>
    ...
</policy>

Privileged access classification is a policy object, meant to apply policies and rules to the objects to which it is assigned. Pre-configured Privileged access classification applies policy rules to affected objects, marking them with Privileged access mark.

The Privileged access mark is designed to mark objects that provide or have privileged access.

Privileged access mark

<mark oid="c58394cd-c883-4e41-927c-f90a7c7a0c97"
      xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3">
    <name>Privileged access</name>
    ...
</mark>

The Privileged access mark can be used in searches, dashboards and reports. Objects marked with the Privileged access mark can be found by querying the effective mark reference:

Unowned mark query

effectiveMarkRef matches ( oid = "c58394cd-c883-4e41-927c-f90a7c7a0c97" )

Default midPoint configuration includes Privileged roles and Privileged users object collections which can be used to locate roles and users with privileged access.

This mechanism is used by the default compliance dashboard to show widgets displaying privileged roles and users.

Privileged access in compliance dashboard

Classification and mark duality

There is Privileged access classification, as well as Privileged access mark. Both of them have their purpose. Privileged access classification is a policy object. It contains policies that are to be applied on objects that are classified (assigned) with Privileged access classification. The result of these policies is marking of all affected objects with Privileged access mark. I.e. marking by Privileged access mark is an effect of policies present in Privileged access classification.

As a rule of thumb, the Privileged access classification is a policy, it should be (manually) assigned to application roles that provide privileged access. Assignment of Privileged access classification is a deliberate act of identity administrator. The resulting Privileged access mark is a status indicator. It marks objects that either provide or take advantage of privileged access. Privileged access mark should be used for reading, such as searching for objects and reporting. Privileged access mark should never be manipulated manually (such as applying or removing the mark), it should always be a result of policy computation.

Limitations

Privileged access mark is applied to users that have privileged access. However, it is not applied to (business) roles that transitively provide privileged access by including (inducing) application roles classified as privileged access. This is a limitation of midPoint computation mechanism (clockwork).
Currently, there is no concept of privileged entitlement. Application roles are not classified as Privileged access automatically. Current implementation of privileged access tracking assumes manual classification of application roles.

Compliance

This feature is related to the following compliance frameworks:

Introduction

Implementation

Limitations

See Also

Compliance