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 Policy Based Access Control (PBAC), which is an advanced framework to centrally manage permissions on business resources. SDS complements the already existing access management capabilities based on Role Based Access Control (RBAC) framework. For Virtual private cloud subscribers SDS complements the already existing access management capabilities based on Attribute Based Access Control (ABAC) framework. SDS encompasses several services to solve the fine-grained access needs of enterprises. One of the key backend services is Resource Access Management (RAM), which provides an interface to configure and manage policies for several business objects.
Access¶
During the first stage of general availability, by default, Secure Data Sharing Policies are not activated in your environment. To gain access, please contact our support team.
User Permissions
Be aware that through enablement of Secure Data Sharing Policies on your environment, all [Standard Users] and [Subtenant Users] lose access to all SDS protected resources. You will have to create policies to grant access again.
For accessing the [Policy Editor] 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
Please note that 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 3 entities namely, [subjects], [actions], and [resources / resource groups]. In short, this means WHO as a user will get access, WHICH resources will be accessible, and WHAT actions will be allowed on those resources (eg. Add, Delete, Read, Write, etc.).
A policy describes a given set of subjects and is allowed to perform a given set of actions on a specified set of resources. More 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. These various terms used are explained below.
Since a policy always grants access and has no provision to deny access, overlapping policies, where the same user may have access granted via multiple policies, have no impact.
A policy can be deactivated any time, and policy is bound to the environment.
To understand Policy schema in detail, please 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 need not be touched if the resources only need to be added or removed from the Resource Group.
To understand how the resource and resource groups are structured in a policy, please 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.