Over the last year we developed a robust framework around Qlik for our clients. However one issue remains due to our industry and data security. We have a couple of scripts that are loaded as includes that pertain to data security access. I can find no way to secure them from a developer and/or sponsor(we allow clients to develop apps).
We secure data at both the database levels and application-section access.
There are two issues:
(1) Anyone can simply comment out the lines (in DLE) and our security is non-existent. While there are some protections in that we have hooks to certain objects that won't work right without them and/or database roles that block data manager row level access, etc., it's not enough.
(2) The debugger loads the scripts and walks through each line. This scripts are tested and placed in secure paths on servers with hidden(can't see through folder connection that way or access through the other debug tool). But I cannot stop the debugger in DLE from walking through each line of these scripts.
I've tried to review most all Qlik API's, REST, SDK's, etc. and I can see no real way to do this. I've also tried OS level file permissions.
The primary is to block the debugger from showing the script or block the include from being debugged.
The secondary would be to lock sections that would just have our one include line from being accessed and/or deleted, ie protected.
The final issue we don't want anyone accessing code they can copy and debug and reveal security details which the above achieves.
What are the possibilities?
This is now a security issue as we have upcoming FISMA audits and we could potentially expose data to unauthorized personnel in a clinical setting.
Hi @JuanGerardo , good idea and exactly what I was hoping for but in a broader sense since QSE uses node. There are many companies using the V8 engine for JS, so I assume Qlik could interface with that if they don't already. I should be able to execute remotely on the server and then it auto-embeds the results in the application much like if I reloaded through the task scheduler.
But the issue is these script(s), one in particular runs 800 lines of tightly coupled section access scripts so I don't see where I can return results and do the same embedded types of artifacts. Much of this relies on Qlik's own script syntax for section access and looping through all application tables then adding our key column values for both SA and data reduction layers. It's complex, so no budget to rewrite at this time.
I guess I hoping for a realization from Qlik that now at almost every level organizations are adhering to Federal security guidelines which means locking down access at every level. So the easy solution is to have a security rule(s) that can go another level deeper and define resources around scripts and sections within the loading editor. Possibly they do but I don't see it anywhere. That should handle this easily and within their current security rules framework. I see this as a very high priority but then again... 🙂
Well, another option is to have your own SaaS platform, as we have in Mercanza. So you have control on the data, the access, the code and the security rules, so you can comply audits. Even you can build a web layer on top to better control everything and integrate with customer authentication systems.
We have web controls for all users on our capacity for the general population, so that's secure as is everything in production closed apps. What I meant was that any developer(pro lic) can get to the scripts while developing applications so I'm not sure how we stop that. We are moving to SaaS eventually but I'm not sure how a developer can be blocked access to scripts he's actively developing on easily.
I think this just calls for a security rule to either attach to a folder/file in the include that allows execution but no debugger, that way they can't read it at all. or the other option is to lock sections in DLE.
Can you explain how I can obfuscate the scripts with your suggestion or tell me which product you have that will do that without extensive refactoring?