How to block the STORE statement for users using Binary Load?(QLIK CLOUD)
Hi everyone,
I am facing a critical security concern regarding Section Access and Binary Loads, and I would like to know if there is a way to prevent it.
The Scenario: I have a base application with Section Access properly applied to restrict data visibility. Another developer user consumes this app's data model using a Binary Load.
The Problem: The issue happens when this developer uses the STORE statement in their script to export the loaded tables into QVD or TXT files. The exported files are created without any access restrictions. The Section Access rules are completely bypassed in the stored data.
The Security Concern: Because of this behavior, a developer can easily extract restricted data into unrestricted files. I consider this a severe security risk and data leakage problem, and I am very concerned about the platform's data governance in this scenario.
My Questions:
Is there any way to block, disable, or restrict the use of the STORE command for developers who are using a Binary Load?
Are there any configurations, security rules, or best practices at the QMC/Tenant level to prevent this specific type of data extraction?
I understand that we could segregate access using Spaces. However, these developers need to access the data spaces to perform the Binary Load and consume the data model. Even if we restrict their write access to corporate Shared/Data Spaces, they might still be able to STORE the data into their Personal Spaces. How do you handle this architectural dilemma without completely stopping the use of Binary Loads?
Any insights or workarounds to secure this architecture would be greatly appreciated.
For context, what is the idea behind a developer using Binary and then modifying the data model? The section access should have persisted, so the capability of the STORE command exists at the base app or the secondary (binary) app.
Can you elaborate the team dynamic for more context?
I would question why you would opt for binary loads in the first place. If you have a properly well constructed QVD layer then front end apps can just do optimised QVD loads from that layer.
You still have a similar problem, in that if a user has the ability to load from a QVD they can STORE the content of that QVD elsewhere.
The way that this is controlled is by not giving access to the spaces where the raw data resides and only giving access to managed spaces with published apps. Self-service type users can still build their own sheets and visualisations in these apps, with the proper section access in place.
If you need users with restricted access to data to be building your load scripts and data modelling then you will need to create separate data spaces and burst subsets of data into those spaces. You can then give an application developer access to a space with reduced data, so they can build the app, and then have the published app load from a different location with the full data. This can be done by switching the location before the app is published and then refreshing after publication. You may hit some snags with app ownership and permissions, but app ownership can be changed in QMC.
I was always under the impression that the STORE statement would respect the Section Access. Was that always this way (including QlikView and Qlik Sense)?
@marksouzacosta In QlikView you could enable a setting that would block the app from being able to be the source in a binary load. You could also restrict access to the reload script.
But to my knowledge, in all Qlik products, once the load script starts section access is ignored. If the STORE command was used, then it applies to all data. Any section access is applied post-reload.
If a user has access to the load script to be able to write the STORE statement, then they must also have access to the code that does the section access and the location where the source file is located. Even if the section access did apply during the load (which I had always assumed it didn't, thanks @lead_with_endpoint_cd for confirming) the user could change the script to allow themselves access - even if the section access script was locked (as you could do in QlikView) they could issue a statement to drop the field used in the section access to give themselves access.
The only safe way to do this is as I described above, with spaces which contain subsets of the data for development. You would also need a UAT space, with all of the data, for testing before promoting to the live space. In each environment the app would need to load from the correct data space.
All requires careful planning and execution if your devs mustn't see all of the data.
