Resource Access Management¶

Idea¶

Secure Data Sharing (SDS) enables you to create and manage fine-grained access rights. It is based on industry standard paradigm PBAC, which is an advanced framework to centrally manage permissions on business resources. SDS complements the already existing access management capabilities based on RBAC framework. For Virtual private cloud subscribers, SDS complements the already existing access management capabilities based on ABAC framework. SDS encompasses several services to solve the fine-grained access needs of enterprises. One of the key backend services is RAM, which provides an interface to configure and manage policies for several business objects.

Access¶

During the first stage of general availability, by default, SDS policies are not activated in your environment. To get access, contact our support team.

User Permissions

Be aware that through enablement of SDS policies on your environment, all Standard Users and Subtenant Users lose access to all SDS protected resources. You need to create policies to grant access again.

For accessing "Policy" in the "Settings" application, you need to have the respective roles listed in Resource Access Management roles and scopes. By default, these are enabled for users with the role Tenant-Administrator.

Basics¶

Once the Resource Access Management switch is turned ON in the "Settings" application, by default, all access to the resources (Assets, Time Series Data, Events, Files and Folders in the Integrated Data Lake) participating in Resource Access Management is denied. Access can then only be granted via policies.

Note

Once Resource Access Management is provisioned for your environment, it takes up to 1 hour to reflect the change. Similarly, requests for policy quota upgrades also take up to an hour to reflect.

Exceptions

There are some exceptions to this rule:

A user having the role Tenant-Administrator is allowed unrestricted access to all the assets, events, and timeseries data of that environment for out-of-the-box applications (like Asset Manager, Insights Hub Monitor, etc.).
A user having the role Data Lake Manager is allowed unrestricted access to all folders and files in IDL inside this environment.
Third-party or custom applications would still need a valid policy to access resources, irrespective of the Tenant-Administrator or Data Lake Manager user role.
A technical user (without Interactive User Impersonation) has unrestricted access to all the resources of the environment, irrespective of whether the user is added to a policy.

Policy¶

A policy, at high level, consists of a mapping of three entities namely, subjects, actions, and resources/resource groups. This specifies who gets access, which resources are accessible, and what actions (like Add, Delete, Read, Write) are permitted.

A policy outlines which subjects can perform specific actions on designated resources. Further details about the policy resource groups is mentioned in below section. Set of actions, and resources are bound by a rule, and a policy can have multiple rules.

Since a policy always grants access and has no provision to deny access, overlapping policies where the same user may have the access granted via multiple policies, have no impact.

A policy can be deactivated any time, and policy is bound to the environment.

For more information on Policy schema, refer Resource Access Management API Specification.

Resource and Resource Group¶

A policy resource represents either an individual business object (Asset or IDL File/Folder) or a Resource Group containing one or more individual business objects. In a nutshell, Resource Group is a container of heterogeneous resources.

One resource can be associated with multiple Resource Groups. A Resource Group cannot contain another Resource Group. That means nesting of Resource Groups is not supported.

With the following advantages, Resource Groups allow for more flexibility in managing access to member resources:

Within the same policy, administrators can manage a greater number of resources when properly organized.
Policy configuration does not need to be adjusted if only resources are being added or removed from the Resource Group.

For more information on how the resource and resource groups are structured in a policy, refer to Resource Access Management API Specification.

Attribute Based Access Control (ABAC)¶

Note

ABAC is supported only in Virtual Private Cloud environments.

Secure Data Sharing service provides Fine-Grained Access Control using Policies, where the Tenant Administrator configures the resources inside policies. These resources can have attributes or properties i.e. metadata key values. Similarly, users can also have their own attributes or properties. More granular and flexible access control of resources can be managed using resource or user attributes or properties. This authorization strategy is known as Attribute Based Access Control (ABAC). ABAC takes numerous factors into consideration while allowing access and offers an additional layer of protection over and above basic SDS. It also permits multiple access scenarios with minimum administrative supervision. ABAC is helpful in environments that are growing rapidly and helps with situations where policy management becomes difficult to handle.

Limits¶

There are certain limits on the amount of policies and few internal objects within a policy. These are listed in Policy Limits.

Known Issues¶

For any known issues, refer Known Issues.

*[PBAC]: Policy Based Access Control *[RBAC]: Role Based Access Control *[RAM]: Resource Access Management *[IDL]: Integrated Data Lake