2.3 What is an Access Rights Profile?

The Access Rights Profile provides in-depth information about a selected access right for the specified time frame, such as:

  • Users or accounts that have been granted the access right

  • Method whereby those users or accounts obtained the access right (directly or inherited from another access right)

  • Additional access rights that the user inherits when granted the specified access right

  • Number of users who have inherited access rights, either granted directly or inherited through this right

The example for exploring an Access Rights Profile describes how a compliance officer might discover a problem where inherited access rights are granted inappropriately to an identity.

2.3.1 Example for Exploring an Access Rights Profile

Ken in Compliance received a request from the manager of Facilities Security to investigate how an unauthorized employee was able to access a secured campus location. First, Ken calls the employee’s manager, Sarah Gibson, to find out what happened. Sarah tells him that a product manager had asked her to attend a meeting with him at the R&D building, but she sent Emma Belafonte as her designate. Emma and the product manager walked over together. Since Emma was the first to the door, she naturally used her badge to enter. As a new employee, she didn’t know that her badge should not have worked. The product manager expressed surprise that she had access, so Emma asked Sarah about it. Sarah, also surprised, contacted Facilities Security to report that something might be wrong with the access rights associated with Emma’s badge.

Ken knows that employee badges are mapped to roles associated with specific access rights. The access right to the R&D building is R&D_building. Usually, employees receive that right through the R&D Group Access role.

In Users & Entities > Search, Ken searches for Emma Belafonte. He opens her profile to check the access rights assigned to her. She has the usual rights for a Customer Relations Specialist. However, she also has an access right called Project_Bluebird. Ken does not recognize Project_Bluebird, so he selects it. In the Access Rights Profile, he learns that Project Bluebird is a special project for the Executive Committee related to a new streaming media effort. A quick call to Sarah confirms that Emma is indeed on that project team, so the access right is appropriate for Emma.

The Access Rights Profile lists all users who have this right. Ken recognizes the names of many of the listed users. He realizes that these individuals likely have access to the R&D building, such as a vice president and an engineering director. He begins to suspect that the Project_Bluebird right might inadvertently grant Emma access to the R&D building. To see what access rights are also granted with Project_Bluebird, Ken selects Hierarchy. As shown in Figure 2-1, the Hierarchy chart includes access rights such as Confluence.PBB.user, Sharepoint_PBB, and project_managers. He expands each of the child rights to find out what rights they grant. Ken discovers that the project_managers access right also grants the R&D Group Access role. And this is how Emma was able to access the R&D building.

Figure 2-1 Hierarchy of the Project_Bluebird Access Right

Ken creates a report of his findings. He includes a copy of the expanded Hierarchy chart so Facilities Security can quickly see how Emma unexpectedly received the access right. He also provides recommendations for how the structure of either the Project_Bluebird or project_managers access right might be changed to mitigate future unauthorized access. As a final step, Ken sends an email to Emma and Sarah to give them a high-level view of what is happening and to expect that Emma’s access to the R&D building likely will be removed.