This section describes how permissions (i.e. access rights) that are collected during the Permission Collection process and analysis task are represented in Data Access Security.
Many of the key Data Access Security Permissions use cases involve gaining visibility to actual active involvement of management in permission reviews.
Permissions describe the access that a specific User or Group has on a specific Business Resource.
Examples of permissions include:
- Mary Jones has Read access to the Finance folder directly.
- John Smith has Write access to the Finance folder because he is a member of the Finance AAD Group.
- Larry Taylor has Write access to the Finance folder directly because he is a member of the Admins AAD Group.
Atypically, a permission may also include an Allow/Deny modifier.
Basic rules are used to model permissions from various systems into a single coherent view.
Every permission consists of a combination of the following four elements:
- Business Resource
Not all components are required for all permissions, since some systems provide direct permissions to users, while others only enable permissions through groups.
The user is an object that represents an account associated with a permission.
Standard user attributes include:
- User entity type - User, local account, or special account.
- User disabled / enabled - Whether the user account is enabled or disabled in the managed application or the identity store.
- User domain - The security domain in the identity store in which the user is defined.
For example, when an identity collector is set on an IdentityNow source for Azure Active Directory, extended attributes may be Department and Manager.
A group is a container of users in a group, responsibility, or profile.
Some endpoint systems only set permissions through groups.
Standard group attributes include:
- Group Type - Often provided in accordance with the group type, depending on the type of endpoint system.
- Group Domain - The security domain in the identity store in which a group is defined.
Normally, it is possible to nest Groups such as that one group resides within another group. For example, assume that Group A contains both User A and User B. If Group A is also a member of Group B, then it follows that Group B also contains User A and User B. Data Access Security examines all nested groups when it analyzes which entities are effective group members for a given group.
Permissions are functions enabled or denied to a user or group.
Permissions are identified for out-of-the-box supported systems.
The standard permission attributes (that provide context) include:
- Permission Type - The function name
- Access Control List (ACL) Allowed - Allow or Deny
- In Inherited - Defined locally or inherited
“Is Inherited” is crucial to Permission queries, since it eliminates permission duplication by showing only unique permissions.
Most permission mechanisms utilize a special Owner permission type. Typically, the Owner permission cannot be blocked, revoked, or customized, and provides full access rights.
Different applications and permission mechanisms may interpret Owner permission differently. The table below describes the permission types that Data Access Security treats as an Owner permission. For each platform, the Owner permission is defined and named (queried by the listed name in the AFM query filter controls).
|Microsoft ACL||Microsoft Access Control Lists contain a special field that indicates the owner user/group of the resource (for example, a file or a folder). There can be only one entity defined as the Owner (but that Owner can be a group). Since an Owner has full control of the ACL, the Owner effectively grants all permissions. The Microsoft ACL Owner applies to:
|Unix||When a file(/folder) is created in Unix/Linux, its creator is automatically set as the Owner. Permissions are categorized by:
|SharePoint||A SharePoint server features Site Collection containers, which function as separate entities, and permission scopes. Different Site Collections may have different users, groups, and permission types. One or more users in a Site Collection may be defined as a Site Collection Administrator. The Administrator has full control of the resources in the Site Collection’s inner structure. The SharePoint Site Collection Administrator applies to:
|Cloud Storage Providers||Typically, cloud storage providers include a permission type named “Owner” which grants full access rights to the resource (file, folder etc.). The generic “Owner” permission is employed in:
A business resource (BR) is a monitored application object, such as a folder on OneDrive or Sharepoint Online.
Business resources can have child BRs and can inherit permissions from a parent resource.
Standard business resource attributes include:
- Name – Name of the resource
- Full Path – Path with all its hierarchy levels (a unique business resource identifier, for example C:\Finance\CTO)
- Inherits Permissions – A flag identifying whether or not a business resource inherits permissions
In cases applications support file level permissions, the business resource tree will include BRs on a file level, where:
- The application is configured in the setup to includes file level permissions.
- The file has unique permissions, compared to its parent nodes.
While inheritance can make management easier, it also can result in unnecessary duplication.
Permission analysis analyzes inheritance by determining whether a business resource inherits permission, and whether a specific permission is inherited.
The table below lists the relationships involved in permission analysis.
|Business Resource Inherits Permission||Permission is Inherited||Result|
|True||True||The permission is not unique and derives from the father permission.|
|True||False||The permission is unique and even though the business resource inherits permissions, the specific permission is not inherited. This is a common scenario in NTFS.|
|False||False||The permission is unique.|
|False||True||The permission is unique.|
The last case in the table is a situation that occurs in a few specific end systems (as it is logically inconceivable). For example, the system enforces SharePoint Policy Rule Permissions from the Web application level. Therefore, even if the business resource does not explicitly inherit any permissions, permissions are still inherited.
The table below lists examples of the results of combining specific permission elements.
|Folder X||Read||Asmith||Group1||User Asmith has read permission on Folder X derived from Group1.|
|Folder X||Read||Asmith||User Asmith has a direct read permission on Folder X.|
|Folder X||Read||Group1||Group1 has read permissions on Folder X. The group is empty.|
Permission Collection Process
Permissions Collection is a process that discovers and collects permissions on the BRs (business resources, such as folders) of an application. These permissions are later used and displayed in Permissions Forensics.
The task itself is a Permissions Collection task.
The permission collection uses one Permissions Collector Engine and zero or more Permissions Collectors.
In applications that support file level permissions, and where activated, the Permission Collector will read all files/objects with unique permissions. This means objects with different permissions than the resource where they reside. These will be considered as business resources in the resource tree, and will support data ownership.
Configuring and Scheduling the Permissions Collection
Permissions can be analyzed to determine the application permissions of an out-of-the-box application, provided you have defined an identity store for Data Access Security to use in its analysis, and you have run a crawl for the application.
The permission collector is a software component responsible for analyzing the permissions in an application.
The Central Permission Collector Service is responsible for running the Permission Collector and Crawler tasks.
Central Permissions Collection Service
Select a central permission collection service from the dropdown list. You can create permissions collection services as part of the service installation process.
Scheduling a Task
The following are options for scheduling a permission collection task:
Create a Schedule - Select this option to view the schedule setting parameters.
Schedule Task Name - The name for this scheduled task. When creating a new schedule, the system generates a default name in the following format: [appName] - [type] Scheduler
You can override or keep this name suggestion.
Schedule - Select a scheduling frequency from the dropdown menu.
- Once - A single execution task runs.
- Run After - Create dependency of tasks. The task starts running only upon successful completion of the first task.
- Hourly - The start time for the task.
- Daily - The start date and time for the task.
- Weekly - The day(s) of the week on which to run the task.
- Monthly - The start date defines the day of the month on which to run a task. Max interval number of 12.
- Quarterly - A quarterly schedule with a max interval of 4.
- Half Yearly - A schedule with a max interval 2.
- Yearly - A yearly schedule with an interval of 1.
Date and time fields - Fill in the scheduling times. These fields differ depending upon the scheduling frequency selected.
Active Check Box - Check this to activate the schedule.
When scheduling a task, be aware that the default time is in UTC.