Introducing Enterprise-Grade Access Control in Kyligence’s Big Data Analytics Platform v.2.5

Controlling access to sensitive data is a vital part of data security for any large enterprises. In many situations, a company needs to control data access on a fine, granular level.

For a large commercial bank with many branches, each branch may only be allowed to see its own data, not that of other branches.

And for a hospital system, a doctor may only be allowed to see information related to her patients only, in order to protect the privacy of other patients. Similar needs to control data access exist in many other industries.

Without granular access control that enables different views of the same data source, IT administrators usually need to create multiple tables or views tailored to each different type of users.

This method creates additional work for busy administrators, increases data maintenance cost, and complicates the ability to maintain data integrity and consistency. In Kyligence Analytics Platform (KAP) v.2.5, we introduce four levels of data access control to solve this problem.

KAP v.2.5 enables different users with different permissions to access only the data they should see, down to the cell level, while operating on a single, unified data source and semantic layer. The four levels of security are: project-level, table-level, row-level, and column-level.

Figure 1 – Overview of Access Control Structure

Project-level Access Control

A KAP user can use project-level access control to determine who can see which project and use which functions within that project. There are four types of access permission roles supported at the project level. Each role defines a list of functions a user may perform. After the administrator assigns the access level to a user at the project level, that user will inherit the same access level accordingly on the data source, model, and cube.

Project-level access control is the foundation to achieving multi-tenant scenarios. A user is given permission on each project independently, and can thus import data source, create models, and query cubes independently as well. This is essential to many large enterprises’ information security, because they typically have multiple departments accessing one system.

Figure 2 – Project-level Access Control

Table-level Access Control

Table-level access control, as the name implies, can control who sees what data on a per-table basis. In a typical use case, table-level access control is configured in a multi-dimensional table that contains private information.

Applying this to a bank, the information being restricted could be the bank account holder name, telephone number, and personal identification number. The need for table-level restriction is common in a bank’s information system, because of the data’s high sensitivity.

Figure 3 – Table-level Access Control

Row-level Access Control

Row-level access control provides security down to the specific rows within a table. One use case where this level of control is necessary is when a sales manager of a large enterprise wants to be able to view the sales data in the region she is in charge of.

Using KAP, the IT administrator would be able to give this sales manager visibility into just her region, while restricting access to similar sales data from other regions. Row-level access control can be applied regardless of whether the user’s query is run on cube, table index, or is pushed down.

Row-level permission is executed in a standard SQL WHERE clause as one of the conditions. If there are multiple values to filter from the same column, you can use the logical operator, OR, to append these values. When you set values filtered by multiple columns for the same user, use the logical operator AND to append these columns.

Figure 4 – Row-level Access Control

Column-level Access Control

Column-level access control restricts user access based on specific column(s) of a table. A common use case is when a table includes employee information and non-sensitive information, such as name, gender, contact number, and position, can be viewed by everyone, but more sensitive information like salary should be only accessible to the human resource department.

If a user’s access to a specific column on a table is restricted, this user will not be able to query against this column, regardless of whether it is through cube, table index or query push down.

Figure 5 – Column-level Access Control

Table-level, row-level, and column-level permissions are set on a project-by-project basis. This means if one table is imported to a different project, the table’s previous permission settings are not carried over to the new project, but determined by the new project’s settings instead.

Summary

Our newly released KAP v.2.5 provides our enterprise users with more powerful multi-level access control, where permissions can be managed from broad to granular. A combination of project-level access control and table-level access control offers a unified and flexible permission control toolset that works for multiple subsidiaries, departments, business units, and teams, while all operating on one data system.

Meanwhile, row and column-level access control provide fine, granular data security down to the cell level, so enterprises with sensitive information can effectively keep out unwanted data access to project sensitive information of its employees and customers.

References

For more detailed information on multi-level access control in KAP v.2.5, please see related chapters in the KAP documentation:

1）Project-level Access Control: https://docs.kyligence.io/v2.5/en/security/acl.en.html

2）Table-level Access Control: https://docs.kyligence.io/v2.5/en/security/table.en.html

3）Row-level Access Control: https://docs.kyligence.io/v2.5/en/security/row.en.html

4）Column-level Access Control: https://docs.kyligence.io/v2.5/en/security/column.en.html