But what you can do is make some apps unavailable for certain (or all) users in the QMC > Documents > User Documents > Server > Performance > Document Control > Customize > select the nodes where the app will be available.
TL;DR: it's possible to configure by app, not by node, and don't use NTFS/QVP if you can avoid it
Warning: Long post ahead
When users access QlikView, the authentication of such users (i.e: if they can connect) and the authorization of those users (i.e.: what they can see) is always performed by whatever security system is in place, not by QlikView itself (with the exception of custom users, but I will not care about them here). There is no "QlikView Authentication System", the users come to QlikView already authenticated.
QlikView is a multilayered application, is not a single monolithic .exe, but made up of several service, all of which can be running in one single server or separately in multiple different servers. For the purposes of this post, I'm focusing on two services: the application layer (QlikView Server service) and the interaction layer (QlikView Web Server service).
One way of scaling out and provide more power for more users is adding more nodes (the QlikView Server service) to an environment. A node in QlikView is a replica of any other node, in terms of security and contents, managed centrally by the QMC. Most of the settings in the QMC apply to the whole environment, regardless it is a single server deployment or a multiple server deployment.
Having more nodes means that, by default, the same QVWs will be replicated in each node and made available to users in each node.
There are two ways of accessing QlikView:
Using the Ajax client / HTTP protocol / a browser
Using QlikView native Desktop / QlikView Plugin / QVP Protocol
The difference between them is important, if only because the first requires a web server (usually QlikView's own Web Server or IIS, but it could be Apache or others) which also acts as a load balancer, sending users to different nodes (or to the same node), and the second ignoring the web layer and letting users connect directly to the QlikView Server without passing through a web server using Qlik's proprietary QVP protocol, with the security and architectural considerations this implies.
At this point it's worth considering that QlikView can and will use all the resources in the server, and that a QVW cannot be distributed across different nodes (one "partition" of the QVW residing in one server and another in a different server). Instead, the full QVW will be stored and made available in all nodes. There will be literally as many copies of the QVW as nodes in the environment.
As a performance setting, QlikView introduced the possibility to make any published QVW available in none, one or all the nodes in the environment, so when the user gets to the AccessPoint and requests to open the app, he or she will be directed to the nodes where this app is set up to be available.
But still, all the nodes are available and that user could eventually go to that node to consume a different QVW which is available in this node as well.
However, if QVP is used instead of HTTP, since there is no web server, there is no load balancing, and the user has to specify the name of the node where the application is available. (Tunneling aside, which I will not mention in this post either).
Then, how QlikView knows that the user is who he or she says he is, and let it open the app, how it applies the authorization? Using the QMC terminology, applying one of two available methods:
NTFS authorization (Windows controls file access)
DMS authorization (QlikView controls file access)
When using NTFS, QlikView relies on whatever is set at the Windows filesystem level: if a user has rights to read a QVW, QlikView will make that QVW available for that user. And if the user does not have access to the file (because, for example, is not included in any group or manually in the Security settings of the file) QlikView will not even display that file to that user. The QVW will not appear in either the AccessPoint (if using HTTP) or the folder of applications (if using QVP).
When using DMS, however, the users can be specified directly in the QMC (Documents > User Documents > Authorization > All Users / All Authenticated Users / Named Users).
That said, if QlikView is using NTFS, you can technically remove a group of users from the server local settings and make this node unavailable. This is not the expected behavior and you will have to check with Qlik Support to see if it's supported.
If you are willing to try this, do you have access to the AD tools in order to add and remove users from groups and assign and modify rights for files and folders and the time it takes to modify every time a user should join or leave?
On the other hand, if QlikView is using DMS, you could technically also make all the apps unavailable for that node, but that case, wouldn't it be easier to simply remove the node from the cluster since it will not be doing anything? Or is it enough using the settings mentioned in the QMC > Documents > Performance > Document Control > Customize?