Page History

...

• There are two projects: Ops and Analysis
  • The Ops project Project has one Reporting Workbook called History with three reports contained in it
  • The Analysis project Project has two Reporting Workbooks with two reports in each. Call these Reporting Workbooks Public and Private.
• There are three users: John, Troy, and Anna
• There are two user Groups to start with the following user assignments: Ops Users (John) and Analysis Users (Troy, Anna)
  
  • Ops Users has permission to access all the Reporting Workbooks and reports published inside of the Ops project Project
  • Analysis Users has permission to access only the Public  Reporting Workbook under the Analysis project Project

Scenario 1: Anna Needs Exclusive Access to the Private Reporting Workbook in the Analysis Project

In this situation we must give access to a Workbook that none of our users has access to originally. 

...

1. We make a third user Group called Analysis Private that has access specifically to the Private  Reporting Workbook under the Analysis project. We then assign Anna to this Group while keeping her a member of the Analysis Users Group. This is a good option if we expect the number of analysts to grow in the future and do not want to administer multiple individual users - particularly if scope of role changes over time.
2. We modify the Private  Reporting Workbook specifically and create a user permission set for Anna giving her access. This means we've made an exception for Anna and not Troy.

Scenario 2: Anna Needs Access to a Specific Report in the History Reporting Workbook of the Ops Project

Like the previous scenario, there are a few solutions:

1. Add Anna to the Ops Users Group. However, because Anna does not need access to the other two reports published under the History Reporting Workbook, this overreaches what permissions are really needed. If we reasonably expect Anna will need access to the other reports in this Reporting Workbook, it's not a particular concern. Otherwise this solution violates the notion of least privilege, which is often the basis used in infosec audits.
2. Create a user exception for Anna on the specific report she needs access to within the History Reporting Workbook. We do not need to set exceptions for Anna at the Ops project Project or History Reporting Workbook levels.

You may have realized we could have gotten the same result if we had modified the report in question to be available to the Analysis Users Group. This is certainly valid, but brings along the same concerns and considerations as the first solution does: it creates overreach of permission, which may be undesirable depending on your organization and the definition of roles.

...

While this is a simple scenario, it illustrates a best practice: make sure that you don't create gaps in terms of who can access what. Without practicing due diligence to make sure one user transitions (or a new user is brought in) well, you can create gaps and potentially orphaned reporting that none of your users knows exists. Worse, if employees are exiting it is standard best practice to ensure accounts and access to privileged and proprietary data are closed out to prevent exited employees potential insider threats. If John's account was not deleted or otherwise modified to prevent his access upon leaving the company, he could still potentially access the organization's reporting content.