Granular user security for the gateway
0 vote
Hello,
I might have an interesting usecase which i'm not sure there is a solution for yet, if there is I would like to know.
We have saveral vaults, actually a vault for each in-house project we have. Each of these vaults have specific users in them which maintain(create/read/update) the entries. I did it this so so that the projectowner can maintain the vault and I don't have to maintain every vault individually after the inital creation. All these users are synced with Entra ID, but that's not relevant to my issue.
We have three physical offices currently and each office has an on-premise Devolutions Gateway running in the DMZ. This DMZ subnet connects through our company firewall with each seperate subnet(VLAN) which houses a project. This works perfectly but it seems I just made a massive security gap which I missed initially.
Each user can create his/her own entry in their vault, I can limit their gateway selection if I want too but what i cannot seem to limit is which subnet(vlan) the user is able to connect to when he/she establishes a connection.
For example:
Office A houses projects 1, 2 and 3
Office B houses project 4,5
User X works on project 1, which resides physically in office A and uses the Vault for project 1. Because the project is housed in Office A the user must connect to the Devolutions Gateway in Office A. All is fine up until now because what is preventing the user from making records that can make connections to projects 2 and 3?
Our firewall doesn't know which users makes which connection and I don't want to make a gateway for each project because that would create a massive overhead on our systems and management.
It seems to me that there needs to be a security mechanism in place which can limit a user to specific subnets he can connect to.
All Comments (6)
Hi Maikel,
Thank you for the detailed use case.
Can you tell me which one of DVLS or Hub you are using?
I believe your use case is similar to this one: https://forum.devolutions.net/topics/43431/gateway--network-segregation--group-based
We have an internal ticket for this feature, and we are currently considering its implementation for the next iteration. (Initially, the feature would be implemented for DVLS, and Hub would come later.)
I’ll add your request to back it up.
I’ll let you know when there is an update on it!
Have a great day,
Benoit Cortier
Hi Maikel,
Thank you for the detailed use case.
Can you tell me which one of DVLS or Hub you are using?
I believe your use case is similar to this one: https://forum.devolutions.net/topics/43431/gateway--network-segregation--group-based
We have an internal ticket for this feature, and we are currently considering its implementation for the next iteration. (Initially, the feature would be implemented for DVLS, and Hub would come later.)
I’ll add your request to back it up.
I’ll let you know when there is an update on it!
Have a great day,
We are using the Devolutions Hub Business, all users use RDM.
Thank you for letting me know. I’ll add a note to the ticket.
Benoit Cortier
Is there any update on this matter? I know it's a month ago but for our use-case this missing feature is becoming the dealbreaker on using the gateway.
We are unable to prevent users from different projects to access each others projects with this issue and it's not good enough to pass ISO27001 for that matter.
Thank you for reaching out again.
To be transparent with you, at the moment, we are still in the process of finalizing the 2025.2 development plan. Although we definitely plan to prepare the groundwork for this feature, it’s unlikely that it will be fully implemented in 2025.2. We anticipate having the definitive planning in about two weeks, but I would say it’s safer not to expect this feature before 2025.3 later this year.
Just for good measure, let me check again what you really want:
- A single Devolutions Gateway instance per physical office, in your DMZ.
- Autonomous project owners able to add, remove and modify entries to the project vault.
- All resources available for a given project are all found on some specific subnet (you have a VLAN for each project).
There are workarounds that we adopted ourselves internally for our office network:
Option 1: In your DMZ, deploy one Devolutions Gateway per VLAN. You need either VMs or completely separate machines, each of which do not know about the other VLANs. At this point, you can think of one Devolutions Gateway instance = one VLAN, and, e.g., you only give "Project 1" Gateway access to people allowed to work on project 1.
This is going against what you said here:
I don't want to make a gateway for each project because that would create a massive overhead on our systems and management.
Option 2: Create vaults with read-only access to certain user groups, ensuring that write or admin-level privileges remain restricted. No one can access other VLANs by the virtue that they can’t create or modify entries.
This is going against what you said here:
I did this so that the project owner can maintain the vault and I don't have to maintain every vault individually after the initial creation.
I understand how it’s not completely satisfying given what you said in your original question, but maybe you could use one of these as an interim solution, and pass the ISO27001 requirements until the dedicated feature is officially launched.
We appreciate your patience and will update you as soon as we have more precise information on the roadmap.
Best regards,
Benoit Cortier
Hi Maikel,
Quick heads-up to inform you that the requested feature is currently being implemented as "Virtual Gateways", and will be available in DVLS v2025.3.
Best regards,
Benoit Cortier