Simon Chalifoux

Hi Chris,

This is indeed a very valid use case. We'll note that as a potential feature for an upcoming update.

Did you have success using the DVLS Ansible module to improve secret handling in your Ansible playbooks already, or are you still at the tinkering stage?

Hi Maeck,

To add to Michel's response, I’d say it largely comes down to your comfort level and experience with exposing applications on the Internet. There’s nothing inherently problematic about exposing Devolutions Server, as it’s a web application developed with modern security practices and frameworks. Implementing MFA, Conditional Access, GeoIP fencing, and TOR filtering must be considered in this scenario of course.

That said, the threat landscape is broad, and you'll need to assess whether you have the expertise to deploy and maintain additional controls to protect what is probably a critical asset. A defense-in-depth strategy would involve layering multiple security measures between users and the sensitive information you want to protect.

Adding a reverse proxy would provide limited risk reduction in itself unless it has security features to filter out potentially malicious traffic before it reaches Devolutions Server. A Web Application Firewall (WAF) would be more effective for this use case, though WAFs come with their own complexities. If the reverse proxy includes pre-authentication** , it could help by blocking any unauthenticated requests from reaching Devolutions Server.

If you’re looking to move away from traditional VPNs, modern solutions within the Zero Trust Network Access (ZTNA) or SASE market could allow you to more seamlessly access your applications from anywhere without exposing them directly.

As for Devolutions Gateway, it was designed for remote access and meant to be exposed. Some customers still add an extra layer of network protection in front of it based on their internal security standards, but at its core, it’s similar to exposing a VPN server or appliance.

You’ll find some useful resources below—some related to your initial question and others on hardening Devolutions Server in general:

Azure pre-authentication to a Devolutions Server data source in Remote Desktop Manager - Devolutions Documentation

Devolutions Server security hardening - Devolutions Documentation

Security checklist - Devolutions Documentation

** Accessing DVLS through RDM using Pre-Authentication is only supported for Entra ID Application Proxy though.

In order to enforce requirements such as security posture using Microsoft Entra ID, you would need to setup Single-Sign-On between Microsoft Entra ID and Devolutions server. Your users would then need to login to Devolutions Server using their Microsoft account. At login time, Entra ID would enforce the requirements you have defined in their platform and allow or deny access to Devolutions Server.

You can find the landing page describing SSO here: Single sign-on (SSO) - Devolutions

This would also mean that you also have deployed the components that responsible for evaluating security posture on your client workstations. If it is not a piece of infrastructure that you already have in place or that you plan to use at large in the near future, it might not be practical to go that route for a single application.

I am not entirely sure I understand the question related to associating a vault with link accounts. When we discuss SSO, we are refering to user account used to access the application, not the accounts that are stored inside vaults.

Hi,

While not something we currently offer directly in the product, if you already use one of Microsoft Entra ID, Okta or PingOne as your identity provider for Devolutions Server, you could enforce those kinds of checks at logon directly from the Identity Provider using a concept usually referred to as conditional access, through which, in addition to requiring correct credentials, you can enforce additional requirements such as a compliant security posture for client devices accessing the application.

Adding security posture evaluation through our own client applications is not a feature that is completely foreign to us, but does requires significant development to ensure it would be done right. Being honest, the chance of seing such a feature deliverd in the short term is low

Hi Mario,

To add to what Maurice said, a very important thing to get right if you plan to use PAM and bastion hosts to manage your T0 assets, is to make sure that those systems and their underlying infrastructure components are also included in said T0 and are managed accordingly.

For PAM specifically, it still makes sense for a tiered environment (even for the T0). The benefits it brings can complement those brought by enforcing the use of Privileged Access Workstations.

For bastion hosts, if we limit its definition to hardened hosts on which you RDP/SSH to further reach privileged assets, I would agree that in a scenario where you are already enforcing PAWs, they are probably redundant. On the other hand, if we extend their definition to include modern gateways born in the ZTNA era (like Devolutions Gateway ;)), they can still be relevant as they add an additional protection at the network layer and they can be more granular and convenient than traditional VPNs.

Hi,

Firstly I don't think any of the two authentication backends are going anywhere anytime soon.

I'd say there is less chance to see major development on the Windows Active Directory (AD) side simply because it is a mature technology and Microsoft itself are not releasing any ground breaking feature to this product nowadays, but it is still very robust and knowledge about it is easily available and IMHO it is one of those tech that just works.

Azure Active Directory (Office 365) is the authentication backend Microsoft is currently betting on. If you already plan on using more advanced authentication feature such as conditional access, passwordless authentication, risk-based authentication and are looking to move toward a Zero-Trust(ish) approach, I'd say you should lean more toward Azure AD (although there is definitely a price tag on those features).

The other benefit is that Azure AD is accessible from any location since it is a hosted service, so you won't need a direct line of sight between the DVLS servers and your Windows Active Directory domain controllers (which sometimes is a pill that can be hard to swallow for security teams, especially if you plan on making DVLS accessible from the Internet).

One downside of authenticating with Azure AD is that, for this to be efficient, it need to rely on an internal cache for users and group membership inside DVLS itself so the change you make in group membership can take a moment to get synchronized in DVLS.

At the end of the day, I'd say it really depends on the strategy you have selected for authentication in your organization.

Hi Karl,

My name is Simon, and I work with Devolutions cybersecurity team.

First and foremost, I investigated your report,and I can confirm that this is a false positive. Malware detection engines nowadays rely heavily on behavioral analysis of software to render a verdict and it means that sometime legitimate behavior get flagged. We often work with detection engines vendors to delist our software or to report false positive result.

I hope that I have been able to provide reassurance and feel free to reach out if you have any other form of security concerns related to this specific report.

Thank you. 

Hi,

The previous attempt has been cleared. You can go ahead and create your company again with the invitation code we just sent you by e-mail.

Let us know if you encounter any issue.

Thank you

Hi,

We discovered some issue with our company provisionning mechanism. The HTML content was not sent along in the Welcome E-mail. Unfortunately, there is no way to recover the initial master key at this point. What I can offer you is to delete the last attempt (this way you could reuse the same name/domain) and provide a new invitation code that will allow you to spin up a new company.

We are sorry for the inconvenience.