Security hardening consists of implementing various security measures to protect against cyber threats and ensure the confidentiality, integrity, and availability of the system. The various Documentation and Knowledge Base topics below are organized in a logical order that you can follow before, during, and after configuring and deploying Devolutions Server. They contain useful information, best practices, and steps to follow to ensure that your Devolutions Server is as secure as possible.
The current topic is mostly based on the Security Dashboard. See Devolutions Server Security Dashboard for a list of action items including short descriptions and mitigation measures.
System Requirements and Topologies
The minimum recommended hardware and software specifications for Devolutions Server may vary depending on your intended use. Visit System Requirements to learn what is required for your situation.
Devolutions Server instances can be installed through different topologies. Determine which one is more adapted to your needs in Topologies. Make sure the required ports are available.
Administration Accounts Settings
Prior to deployment of a Devolutions Server instance, some accounts are needed to operate the various services involved in a secure deployment of Devolutions Server.
The administrator count should be no more than 5. Limiting the number of active administrators within the platform will reduce the attack surface of an attacker to only those accounts configured. Having more than 5 administrators can also be a sign of poor segregation of duty within the business unit or organization.
Database accounts should be different for web application, scheduler, and management tools. Minimum privileges should be granted and applied for service and database accounts to operate. Shared and excessively privileged service and database accounts may induce unnecessary security risk exposure.
The default MSSQL “sa” administrative account is a high privilege account that should only be used to manage the database instance. A less privileged user or service account is preferred to reduce impact of compromise.
The first decision is to use either domain accounts for operating the platform or to use local SQL accounts paired with local service accounts. Since this decision is a matter of personal preference, we support both models. See each one of them and what they entail in Pre-Deployment Account Survey and learn how to configure them in Advanced Credentials.
For domain single sign-on (SSO) to be used to connect to the database, you must set the Application Pool to use a domain account to run under. Follow the steps in Configure Devolutions Server to use domain single sign-on (SSO).
Ports and Secure Communication
While Devolutions Server in itself does not dictate which ports to use for any of the resources that it accesses, we still recommend the network segregation security practice. You must consult with your system administrator to ascertain which adjustments need to be made for the system to inter-operate with your infrastructure. See Ports and Firewalls.
Secure communications guarantee the integrity and confidentiality of the data transmitted between the client and the server. As such, it is important to secure LDAP communications with the LDAP Over SSL (LADPS) method. See Domains to learn how to enable it.
After you have configured the Devolutions Server instance and connected through a client application, you can follow the steps in Configure SSL to import a certificate or create a self-sign certificate, create a SSL binding, enable HTTPS, and configure SSL settings in the client applications. Performing these steps right from the start may add a layer of complexity that may prevent you from succeeding in the initial configuration.
Access URI
If you are upgrading your Devolutions Server from a version prior to 2022.1 to 2022.2 or later, follow the steps in Access URI. During the upgrade process or the installation process of Devolutions Server, we must provide an Access URI. This URI is a redirect URL that is used by the OAuth system and redirects the authentication traffic to the Access URI.
Encryption
To ensure that the communication between the Devolutions Server instance and the SQL Server database is encrypted, an extensive procedure must be followed on the SQL Server instance. See Encrypting Connections to SQL Server.
When using SQL Server Login accounts, encrypting the web.config and appsettings.json files is of the utmost importance, as sensitive information is stored in them. Visit Encrypting the web.config File for more information and recommendations.
The encryption key is used to encrypt data entries (connections, user vault, documentation, and attachments). The encryption keys are generated and stored in the encryption.config file on the server only. Learn how to export, import, and regenerate them in Manage Encryption Keys.
For businesses that require FIPS (Federal Information Processing Standards), refer to FIPS (Encryption).
Backup and Log Management
The Backup Manager accessible from the Devolutions Server web interface allows administrators to configure the parameters to back up the database and the web application folder. Backups should be enabled and configured to an external media or cloud storage to avoid permanent loss of data.
Also learn about the requirements and the steps to properly configure the Devolutions Server Backup Scheduler and instructions on how to restore your Devolutions Server instance succeeding a disaster in Backup and Restore Devolutions Server.
Concerning logs, it is recommended to send them to an external system to maintain integrity and availability of event information. Configure the Logging feature in the Devolutions Server web interface.
Refresh Token Lifetime
Excessive session duration may allow exposure beyond necessary to unauthorized users. The Refresh token lifetime should therefore be configured within 24 hours (1440 min.). This can be configured in the Advanced Server Settings via the Devolutions Server web interface.
Email Notifications
An email server configuration is required to transmit important application messages such as security events or errors. They can be configured in the web interface. See Configure an SMTP Email or Configure an SMTP Email With Azure for configuration steps and information on each setting.
Devolutions Server Console Password
It is recommended to add another layer of security by enabling and setting a password for the Devolutions Server Console. Learn about this password setting and all other Devolutions Server Console settings in Devolutions Server Console.
Devolutions Server Security Dashboard
The Devolutions Server Security Dashboard is a tool to offer guidance on how to improve the security of the Devolutions Server platform and also tips on reducing the workload for administrators. Some tips are common infosec best practices, others are a consensus between our own teams. It can be accessed at any time in the Devolutions Server web interface, in Administration – Security Management – Security Dashboard.
The scores are admittedly open to question and we do not pretend each topic has the same relative value for all community members. Achieving 100% is surely not an end goal in itself, we simply aim to raise awareness and provide ideas for your own security hardening.
Give us Feedback