Skip to content

Permission

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.

Permission Modeling

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:

  • User
  • Group
  • Permission
  • 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.

User

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 Identity Security Cloud source for Azure Active Directory, extended attributes may be Department and Manager.

Group

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.

Group Nesting

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

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

Note

“Is Inherited” is crucial to Permission queries, since it eliminates permission duplication by showing only unique permissions.

Owner Permission

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).

Permission Scheme Description
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:
  • Windows File Server
  • Active Directory
  • Microsoft Exchange / Microsoft Exchange Online
  • NetApp - CIFS
  • EMC Celerra - CIFS
  • EMC Isilon - CIFS
    		•
    Unix When a file(/folder) is created in Unix/Linux, its creator is automatically set as the Owner. Permissions are categorized by:
  • Owner
  • User's in the Owners group
  • Other Users
    • There can only one owner user and one owner group per file/folder. Since only the Owner (or root) can change file permissions, an Owner effectively grants all permissions. The Unix file system Owner applies to:
  • NFS (when using Unix permissions, but not NFSv4 ACLs)
  • NetApp – NFS
  • EMC Celerra – NFS
    		•
    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:
  • Microsoft SharePoint
  • Microsoft SharePoint Online
  • Microsoft OneDrive
    		•
    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:
  • Box.com
  • Dropbox
  • Google Drive
    		•

    Business Resource

    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.

    Inheritance

    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.

    Note

    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.

    Permission Examples

    The table below lists examples of the results of combining specific permission elements.

    Business Resource Permission User Group Result
    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.

    Note

    When scheduling a task, be aware that the default time is in UTC.

    Select Next.

    Documentation Feedback

    Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.