Introducing Enterprise-Grade Access Control in Kyligence Analytics Platform v.2.5

10 - 30 - 2017

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. 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: http://docs.kyligence.io/v2.5/en/security/acl.en.html

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

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

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

Recent Post

Apache Kylin v2.5.0 Release Announcement

Apache Kylin v2.5.0 Release Announcement

Sep 20, 2018 • Shaofeng Shi The Apache Kylin community is pleased to announce the release of Apache Kylin v2.5.0. Apache Kylin is an open source Distributed Analytics Engine designed to provide SQL interface and multi-dimensional analysis (OLAP) on Big Data supporting extremely large datasets. This is a major release after 2.4.0. There are many […]
Read More

Quick Start Guide: Kyligence Enterprise on Microsoft Azure Marketplace

Quick Start Guide: Kyligence Enterprise on Microsoft Azure Marketplace

Chapter 1: Take the First Steps to Explore Kyligence Enterprise   In this section, you will learn to install Kyligence Enterprise on a new HDInsight cluster and play with the sample cube using Kyligence Enterprise, highlighting some of the most common tasks. In fact, you can either create a new cluster or use an existing […]
Read More

Scale Your OLAP to Petabytes on Google Cloud Platform

Scale Your OLAP to Petabytes on Google Cloud Platform

Kyligence – the company behind Apache Kylin – announces that its enterprise OLAP (online analytical processing) engine on Hadoop – Kyligence Enterprise – can now run on Google Cloud Platform. Highly integrated with Google Cloud Storage and DataProc, Kyligence scales your OLAP to petabytes of data, make your BI applications work on your data lakes. […]
Read More