
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Qlik Cloud security model to control access to data
I have a big picture data security model question.
First, let me provide some background...
For several years we have been using Qlik Sense Enterprise for Windows, and we are moving to Qlik Cloud. We have established a Data Gateway to the Cloud Server from our data warehouse / data lake, and I can pull data from that data lake into apps in Qlik Cloud, and store tables into QVDs.
Our organizational data is small relative to a lot of other users (we are a regional sized business, not Fortune 1000). In our on-premises data environment, our data lake resides on a SQL Sever database. We partition data into schemas (they are like data owners or data partitions) in the database. We control access to groups of data using AD groups, and grant those groups access to one or more of about about 50 different schemas, and therefore the data in those schemas.
Looking at the data gateway, it does not appear that there is a way to limit or partition access to portions of the data using security tools associated with the data gateway. But we need control over who gets to see what data. I need a security model for that.
My current thought is that I will create one space in Qlik Cloud for each of our schema data groups in our local data lake. I will create an app to load QVD files (one app for each schema), which loads data for a local schema into a collection of QVD files in a mirrored Qlik Cloud space. I will then use our active directory groups to control user access to the Qlik Cloud spaces in the same manner that we control access to schemas in our local data lake.
If I do it right, our developer community will have access to the same data sets in the cloud as they have locally.
Does this seem like a reasonable approach? Is there a better approach that I have missed? Any insight that you can provide would be greatly appreciated.
Moving to the cloud will involve both moving our data sources, and then moving the dashboards that depend upon those data sources and redirecting them to the cloud version of data. If we are careful up front, redirecting each dashboard to a new cloud data source should be a simple task.
Our Qlik license model relies upon entitlements, with users assigned to Professional, Analyzer, or Analyzer Capacity entitlements.
In playing around with this approach, it appears that we can only assign an entitlement to either Qlik Cloud or Qlik on-prem. If this is so, we will need to stage groups of users, moving them and the dashboards that they depend upon as a group -or- moving a small test group to prove everything out and then implementing a giant "throw the switch" event, where we move everyone else all at once.
We have two sorts of applications. Some are carefully developed and maintained by professional Qlik developers, and carefully validated using curated data sets. These apps change slowly. They have become important many parts of our business. We can move them from our local Qlik instance to Qlik Cloud in a controlled manner.
The other sort of app is developed by our community. Our central app authority doesn't try to keep a good handle on these apps. They are developed and managed by our user base. I expect that we will leave it up to our user base to move these apps when we "throw the switch".... Somehow..... as our user base can only have privileges on the local instance - and then only the Cloud instance...
Does this seem like a reasonable approach? Is there a better approach that I have missed? Any insight that you can provide would be greatly appreciated.
- Subscribe by Topic:
-
Data Marts
-
New to Qlik Cloud Data Integration
-
Qlik Cloud Data Integration

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Data gateway now lets users pass security credentials through the gateway connection to SQL Server. As a result, our traditional approach of using active directory groups to control access to SQL Server schemas (and therefore access to the tables located in those schemas) can now be used. Therefore we are abandoning our data governance approach of using a collection of QVD files stored in spaces to control access to data. We are back to loading dashboards directly from our SQL Server database through the gateway, with our various dashboard developers passing their credentials through the data gateway. This is working well for us.
