Proving Access Control Compliance and Enabling Access Review Reporting
In April 2016, Axiomatics introduced the Axiomatics Review Manager, a one-of-a-kind access review and reporting tool, that can confirm polices are enforced and compliance is met within dynamic authorization implementations with Axiomatics, that utilize an Attribute Based Access Control model (ABAC).
In this blog post, we provide a more detailed explanation of the need that the Review Manager fills, as well as a glance into the inner-workings of the tool.
Maybe you have already taken the right step towards using ABAC for your access control solutions, or maybe, you are thinking of jumping in. Either way, you’re already in a next-generation authorization mode of thinking.
With our latest reporting tool we are helping to further smooth the transition to ABAC, by providing a full lifecycle solution, as well as helping you and enable you to tick the box in your compliance proof checklist.
We’ve heard from customers and prospects alike – that you need more audit and access review capabilities once you’ve implemented new ABAC policies. The Review Manager allows you to meet this need head-on: to generate customizable access review reports about your access control policies, deployed in the production environment. These reports can be used to prove to the information security personnel or a compliance officer that the system is indeed enforcing policies as expected by the IT, business or regulatory policies.
Let’s walk through an example
As you get started, start by writing simple policies. Policies that are along the likes of what a normal employee can do and what a manager can do. Maybe something like a manger can view any records (Rule 1) while the employee only can view records that belong to his/her own department (Rule 2).
That is relatively easy to understand and keep track of. Now, what if we add editing of the document to the mix? Let’s assume a rule (Rule 3) that an employee can edit only those records that he or she owns (is the owner of) and only if the document is in draft stage.
As you can see, things are getting interesting. It still should be possible to keep tabs of what the rules are doing and what policy applies for a specific individual or a role. However, now let us consider the notion of publishing a record. Consider a rule (Rule 4) that only a manager can publish a record and that too only if the record is in final stage and if the record is owned by an employee that the manager is responsible for (manages).
When an application, say a record management system, needs to decide whether a specific action can be performed by a user, it calls out to the Policy Decision Point (PDP) for an answer. The PDP performs the evaluation of the policy and based on the values of attributes, for example the role of the user, the ownership details of the document etc., the action is either allowed or denied. The figure below provides a generic outline of the flow.
This kind of workflow provides organizations with a way of enforcing finegrained access control policies in a dynamic manner. However, there is still a missing piece of the puzzle. Often in large organizations and/or in organization that work in heavily regulated sectors (like finance and healthcare), it become necessary to perform frequent reviews of the access control policies that are in place in the organization.
In such a situation, the questions to be answered are no longer of an yes/no (or permit/deny in the access control lingo) kind, but rather they are open ended questions, such as what are all the actions a user with the role manager can do within a specific system or on a specific resource.
This is where the Review Manager comes in. Built on the unique capability provided by the Axiomatics Reverse Query (ARQ), the Review Manager lets users ask and get answers to these openended questions. ARQ was built using a templatebased framework that makes it easier to reuse for access review needs.
Usage scenarios include
- CISOs compliance officers having to prove that the deployed access control policies enforce specific regulatory or internal IT policies
- Managers needing to perform periodic signoff on subordinates’ access control rights
Application owners, responsible for overall working of an application, needing to know
the access rights associated with users at different levels of grouping (individual, roles, departments, etc.)
How about, what kind of operations can be performed on a specific record, say record #124.
When a report is generated for such a question, one could end up with the following output:
If one ignores the namespace ‘com.acme.’ from the response in order to make the output more readable (sacrificing some preciseness), the reports essentially states that three kinds of actions can be performed on the record #124:
- A manager can view the record (from Rule 1)
- An employee in Finance can view the record (from Rule 2 and the dataset used in this example where record #124 belongs to the Finance department)
- User Bob, if he has an employee role, can edit the record as well (from Rule 3 and the dataset which states that Bob owns document #124)
How about another report: what can Alice do on any (non-specific) document?
When a report is generated with such a question, for this specific example, one could get the following response.
If one ignores the namespace ‘com.acme.’ from the response in order to make the output more readable (sacrificing some preciseness), one can see that the report basically informs that Alice can perform two kinds of actions on a record:
- Alice can view all records, without any additional conditions being met.
- Alice can publish all records that have final status and are owned by Bob.
The result (1) comes from Rule 1 and from the fact that Alice is a manager in this example dataset.
The result (2) comes from Rule 4 and from the fact that Alice is a manager of Bob in this example dataset.
One can also create reports with mixed sets of questions – what can a specific user do on a specific resource:
The report generated would state something as follows:
This can be explained by Rule 1 which allows Alice the manager to view all records, including #124. None of the other rules applied, especially Rule 4, since in this data set, record #124 was in Draft stage.
As you can see, these reports provide valuable insights on the effect of the deployed policies. Not only do these report reflect the policies, but also takes into account the actual values of attributes (role, subordinates relationship etc.) used in the evaluation of the policies.
For ease of management and usage, several of these templated reports can be configured for use by the Review Manager administrator, into different collections. In fact, each such collection can be configured to work against different Policy Decision Points, which means that a single deployment of the Axiomatics Review Manager can be used to create reports against several groups (‘Domains’ in the Axiomatics Policy Server lingo) of Policy Decision Points.
With the launch of the Axiomatics Review Manager we address the auditing, reporting and compliance needs of ABAC and policy-based access control – and hope to further smooth your organization’s transition.
We are constantly looking for ways to improve our products’ features and capabilities. So, if you have any specific suggestions regarding the Review Manager’s functionality that would make it more useful for use within your enterprise, please feel free to contact us.
You may also want to view our webinar that explains the Review Manager in depth.